/agdg/ - Amateur Game Development General

>>22966

I'm struggling to figure out whether webkit is better than firefox. Or do I want a wrench or a bolt gun?

>>22966

What a mysterious post

Obviosly SDL is popular and feature lacking for casuals

GLFW totally lost me

SFML is for people who love extensibility and memory leaks?

The last 2 are tools so the bolt gun is more advanced and thus overkill for simple projects?

>>22969

>>22974

I get what he's saying.

SDL in its current inception is slower and heavier than the rest, and it's fucking huge. It's also the most popular, especially for starters.

Webkit isn't a browser, just a simple layout and rendering engine. It needs a lot of other parts to be functional. In the same way, GLFW includes no bells and whistles, just giving you cross-platform context creation, and input and window management.

SFML is faster than SDL, offering much of the same capability, but much more flexibility. (I haven't had a memory leak in Firefox in years. Extensions can have leaks, though, and that might be what you're seeing).

I don't know enough about PortAudio and OpenAL to directly compare them, but I do know that the official OpenAL implementation is proprietary (there are open implementations, though).

>>23018

About OpenAL etc.

The open implementations of OpenAL like OpenALSoft use DirectSound or PortAudio internally.

It's really hard to decide how to do cross platform sound.

>>23018

>SDL in its current inception is slower and heavier than the rest, and it's fucking huge.

I've never used SFML, would be nice to read a source on that. I've been sticking to SDL because it seemed to be more stable/reliable due to it's age and widespread.

>>23031

I've used SFML previously. Release 2.0. It was pretty rock solid, the only problem I ever had with it was around text rendering. They were reading glyphs slightly incorrectly, but I found the problem in the source and fixed it for them.

But all in all, it was rock solid, easy to use, well documented. Building it from source was a walk in the park, it came with all the external libraries pre-compiled.

>>22879

>>22876

How is Qt? I've seen it used in SFM and it looks pretty slick, but how is it to work with?

>>23031

 % ls -lh /usr/lib/libSDL2.a 
-rw-r--r-- 1 root root 1.7M Aug 11 11:59 /usr/lib/libSDL2.a

 % ls -lh /usr/lib/libsfml-*.a
-rw-r--r-- 1 root root 196K Aug 11 12:01 /usr/lib/libsfml-audio-s.a
-rw-r--r-- 1 root root 699K Aug 11 12:01 /usr/lib/libsfml-graphics-s.a
-rw-r--r-- 1 root root 176K Aug 11 12:01 /usr/lib/libsfml-network-s.a
-rw-r--r-- 1 root root  48K Aug 11 12:01 /usr/lib/libsfml-system-s.a
-rw-r--r-- 1 root root 119K Aug 11 12:01 /usr/lib/libsfml-window-s.a

(about 1.2 M altogether)

SDL is monolithic and inseperable, whereas with sfml, you only have to use what you need. SDL is also slower, rendering without hardware acceleration by default, where SFML always is hardware accelerated when possible.

You're right about reliability, though. SDL is way stable and reliable.

Why not write plugins for existing engines to use for your specific game(s)? Talking about dialogue system if needed, or something else you feel is missing? Who here uses an engine but writes/extends it with his own or other's plugins?

>>23248

I wouldn't call that engine dev. Engine dev would be building the ability to have custom coded plugins in the architecture.

>>23208

Qt is some ways is a bit more bare fucking bones than something like XNA, but it has a lot of advantages.

1. C++, that's some raw speed right there, only things that suck about this language are the compile times (but that's minor). Pointers may seem nasty but their nice (and Qt has some stuff to make managing them easier).

2. Cross platform Widgets/GUI. It's really nice, they have a lot of widgets for you already available. They can either be native or you can change how they are drawn (to your liking)

3. Other things like Threading, Timers, Networking, Geometry, are built in (and cross platform).

4. If you want 2D and 2D only, look no further than the GraphicsView Framework. It may seem very abstract at first but it's really nice.

5. If you want 3D, get ready for some (near) low level OpenGL shit.

I think it's a really good option for video games engines that gets looked over a lot. They even have cross compilation support for mobile devices too!

I suggest it highly if all you know is C++.

>>23255

I've been working with GLFW and I was planning on writing my own UI from the ground up, but that definitely looks like a decent option. I'll look into it.

>>23301

Best thing I can recommend is to go through all of the OpenGL examples on the official website. Use Qt 5.x. Avoid any tutorials that use the old fixed function pipeline. QOpenGLFunctions contains all of the functions that are part of the OpenGL ES 2.0 standard; I recommend using that for all of you GL functions call.

I've been dabbling.

c++ & modern opengl

entity / component model

fun times fixing random shit in graphics related parts of the code

not too sure what to do for gui elements, maybe chromium embedded framework.

I'm working on an engine using the windows API. I'm trying to figure out how to distinguish inputs from two different keyboards

>>23368

I looked into embedding chromium and instead went with doing the gui myself.

The reason is because I'm an idiot. It's a lot of work to code a fully functioning UI system with some type of data driven design and layout.

>>23371

http://gamedev.stackexchange.com/questions/56361/how-do-i-read-input-from-multiple-keyboards-mice-on-one-computer

>>22939

>>22912

There's no reason to require a layered separation between game and engine, at least for definition. Especially given that there's no programming need for that. It's just generally easier to do so, and you'd primarily stray away for the sake of optimizing out the glue (optimizing for either man or machine, time/effort).

anyways, the entire enginedev concept is a stupid distinction to have in the first place, if it's solely about "where" the programming lies on the architectural scale. It implies that there's a fundamental role difference between two different parties, when really the engine and it's output is intermixed, and can even act in feedback loops.

It'd be much more useful to have a distinction similar to frontend/backend as in webdev, where front is the WHAT happens, and the back is the HOW it manages to do those things. "design" versus "architecture" of the total system.

Only in special situations (typically large businesses) do you have the kind of head count that necessitates a division of labor such that you have a group whose specific domain is the "engine" and another whose specific domain is the "game"..

Enginefag here. I write engines but not games.

I really need to write up an overview on engine stuff sometime for people.

Currently using:

DirectX for graphics (I have a graphicsfag working with me, doing pbr)

C++ core for Component-based and systems

SWIG/Some meta-shit for C# scripting

WPF for editor

As for architecture, if you want to follow the general high-level approach that commercial engines use: you divide your engine into these levels (from high abstraction to low):

GAME LOGIC BITS

1. Runtime Scripting - game logic that loads game data

2. Scripting interface - this is the binds that hold the runtime scripting to your actual engine

ENGINE BITS

3. Components (data only, no logic. Merely data bundles to be passed to systems (e.g. RenderComponent goes to GraphicsSystem, PhysicsComponents to Physics, etc. )

4. Systems (Your actual game update loop e.g. Renderer, Physics, Game State Manager, Audio, Input, Scripting Updates, and FramerateController)

5. Main loop update all systems

6. Fancy optional stuff for underlying core (Meta reflection, job system, etc.)

Each level should only interact with things directly above or below it (except for #6, that can be used anywhere in engine bits)

Notice there's no mention of an Entity or GameObject. In a proper full engine design this concept is indistinguishable from a mere list of components. While it exists, it becomes functionally a part of the Game State Manager and not of the engine as a whole. Component distribution to systems during update can be done almost entirely without touching w/e component container objects.

>>22940

i'm thinking about using ASIO for a simple http server. I hope I haven't fucked up.

>>23429

Oh yeah, as a follow up. If anyone is interested in runtime scripting but doesn't want to dive into the shithole that is binding C# but is too hipster to bind LUA, I highly recommend checking out AngelScript. It's easy as fuck to bind and looks like C++ syntactically.

>>23472

>its way better and simpler than any other game engine ive encountered. It canbe infinitely scaled and its completely modular. The only problem is I have no clue how to sell it

What's the percentage of your code coverage? Do you somehow cover rendering code?

>>23472

>its way better and simpler than any other game engine ive encountered. It canbe infinitely scaled and its completely modular. The only problem is I have no clue how to sell it

What's the percentage of your code coverage? Do you somehow cover rendering code?

>>23473

This. There's no way you made a modular game engine in 500 lines unless you're building on top of existing libs.

>>23540

heh oops looking at the screenshot made me aware of the memory leaks of the game and core classes (although technically the OS would free them anyway).

>>23540

Mine is a little but more verbose (I'm OP).

int main(int argc, char* argv[])
{
#ifdef NDEBUG
    std::ofstream errorLog("SpaceEngineErrorLog.txt");
    std::cout.rdbuf(errorLog.rdbuf());
#endif
    try
    {
        spaceengine::SpaceEngine spaceEngine(glm::ivec2(SCREENWIDTH,SCREENHEIGHT));
        SpecificGame game(&spaceEngine);
        spaceEngine.HookGame(&game);
        spaceEngine.Start(new spaceengine::PostProcessingEffectChain(glm::vec2(SCREENWIDTH,SCREENHEIGHT),"../../Assets/postprocesschain.json"));
    }
    catch(const std::exception& e)
    {
        std::cout << "ERROR:\t" << e.what() << std::endl;
    }
    catch(...)
    {
        std::cout << "ERROR, nothing" << std::endl;
    }
#ifdef NDEBUG
    errorLog.close();
#endif
    exit(EXIT_SUCCESS);
}

>>23593

>spaceengine::SpaceEngine spaceEngine

Just fuck my shit up.

>>23644

Shit, I didn't even see that I did this.

This is only semi-on topic, but: someone made an engine with haskell:

http://helm-engine.org/

Thoughts on functional engines?

>>23684

ehh it doesn't surprise me someone actually did this, probably as a proof of concept thing, but I bet it's useless as actual game-engine and only functional programming language purists would (want to) use it.

It just seems extremely inconvenient for games..

>not developing with vulken

>>23932

How could you?

I wonder if posting my progress would speed up my progress

I don't have much yet though, latest progress is a logging system

INFO : Log file opened - Sun Nov 22 23:10:34 2015
INFO : Core: Creating window..
INFO : Core: Creating renderer..
INFO : SpriteRenderer: Loading shaders..
INFO : Core: Creating server..
INFO : Core: Creating client..
DEBUG : Window: GLFW says the window is closing..
DEBUG : Core: Game loop ended..
INFO : Core: Shutting down..
INFO : Core: Terminating game..
INFO : Core: Terminating renderer..
INFO : Core: Terminating window..
INFO : Window: Terminating GLFW..
INFO : Application has ended succesfully, closing logfile..

So I found that I need to allow for GUI scripting now that my GUI widgets drawing + layout files are complete.

Then I thought, I should probably allow the scripting to do more than just gui.

Then I thought I may as well abstract as much game logic as I can into scripts. So like the engine basically loads everything from scripts with some set functions that will be called.

Then I downloaded a copy of the dragon book.

I've just completed my lexer. Now I need to make a parser etc. Making a scripting language is hard.

>>24042

I accidentially made a crude one when trying to shamelessly rip off the source engine's config system. It was at that point I decided that I'd try to use lua for everything and restrict configuration files from calling functions.

>>24087

I'm attempting to do everything, like everything, on my own, short of my graphics API.

I've now completed a parser that can parse expressions and build a Syntax Tree using a Recursive Descent Parser until it finds an expression, at which point it changes into the Shunting-Yard Algorithm.

https://en.wikipedia.org/wiki/Shunting-yard_algorithm

https://en.wikipedia.org/wiki/Recursive_descent_parser

My scripting language is going to basically be "C with classes and no pointers"

>>24217

> Recursive Descent Parser until it finds an expression, at which point it changes into the Shunting-Yard Algorithm

??? WHY ?!?!?!

>>24293

Because it's super easy to make a recursive descent parser and the shunting algorithm is the only way I know to parse an expression.

>>24217

So your scripting language is going to be angel script?

>>24389

>Because it's super easy to make a recursive descent parser

Which is exactly why you should use it to parse expressions. If you code it right, you can evaluate the expression from the resulting parse tree. Google "recursive descent parser for arithmetic expressions"

See:

http://www.engr.mun.ca/~theo/Misc/exp_parsing.htm#classic

http://blog.roboblob.com/2014/12/16/recursive-descent-parser-for-arithmetic-expressions-with-real-numbers/

>>24217

>I've now completed a parser that can parse expressions and build a Syntax Tree using a Recursive Descent Parser until it finds an expression, at which point it changes into the Shunting-Yard Algorithm.

Mixing multiple parsing algorithms is a recipe for disaster. When shit goes wrong be prepared for many sleepless nights.

off topic sage

>>24429

Oh well, I got it working my way. Which is also the way gcc does it, I think for speed.

>>23371

>distinguish inputs from two different keyboards

Okay you can't just say your game uses two keyboards and not say what it's for

So after a year in Java, then ditching it to rewrite in C++ another 4 months, my engine is finally coming together.

2d voxel game. All entities are voxels. Basically 2d Starmade.

Space partitioning:

unordered_map<uint64, Bucket*>

key = ix+iy<<32

People always say you need rectrees, but I find this works really damn well.

Trees without researcher-tier allocation are cache hostile as fuck.

This only has 2 dereferences/fetch. My impl is like ~30 lines.

Collision:

Continuous so works at ultra high speed, but currently faster speeds need too much bucket gettings

Kinematics:

Fuck torque calculations, All levers are of length 1 lol.

Netcode:

uuuhh.... "80% deterministic"

Basically fuck networking for now, I can't figure out an easy way to test this, and I do very continuous builds

>>27843

> 2d voxel

Those are called pixels.

>>27843

>I can't figure out an easy way to test this

Since you're on based C++ now, then I'd recommend either POCO, Casablance, or ASIO. Since the standards committee will choose a variant of ASIO in C++20, that may be the best choice tbh.

>>24217

so C#?

Why not use mono then?

The thing that's fucking me up hard is cross-cutting concerns. I.E., your program will ALWAYS be a tree if you use OOP, so when you have things on one branch that are needed by another branch you have to connect the two somehow.