next »

[Garthy]

A good reference nowadays when determining a good minimum platform to target:

http://store.steampowered.com/hwsurvey/

Yup, but I have a feeling that most of steam users have computers with specs above the average (just a feeling). I would like to target average computers too (like mine).

If you wish, you could always see where your computer- and by extension average computers- fit capability-wise on the hardware that show up here. If say it was in the lower 10% of the computers in this particular survey, then you know that a good target to aim for would be something that shows up in the top 90% of the data.

You would then have a wealth of data that you can use to ensure that you only use functionality that exists on say 90% of computers that use Steam.

There is a wealth of information here that could be used to guide you on the functionality that is typically available. I have found that studying such data can save considerable development effort.

For example: Quite some years ago I was working on a project and I was trying to determine the amount of effort I should put in to support video cards that could only support rendering one texture at a time. Using a similar list I was able to get a feel as to what was out there. In this case the conclusion was that of the cheapest motherboards sold for the last few years that had any 3D support, there was almost nothing apart from a small number of esoteric cards that were restricted to a single texture. Any effort on supporting this environment was best delayed to a future time. Additionally, as part of studying this information, I was able to determine a number of other assumptions that I could make regarding the capabilities of typical video cards out there. This would have saved me considerable time had I researched this earlier, and it saved me considerable time afterward as I could make a number of educated assumptions about the sort of hardware I could expect to see.

Anyway, I just wanted to share my experience in this regard. Perhaps the suggestion will be more useful to others, and perhaps it might end up being more useful to you at a later stage of development. All the best in any case.

[ferreiradaselva]

If you wish, you could always see where your computer- and by extension average computers- fit capability-wise on the hardware that show up here. If say it was in the lower 10% of the computers in this particular survey, then you know that a good target to aim for would be something that shows up in the top 90% of the data.

You would then have a wealth of data that you can use to ensure that you only use functionality that exists on say 90% of computers that use Steam.

There is a wealth of information here that could be used to guide you on the functionality that is typically available. I have found that studying such data can save considerable development effort.

For example: Quite some years ago I was working on a project and I was trying to determine the amount of effort I should put in to support video cards that could only support rendering one texture at a time. Using a similar list I was able to get a feel as to what was out there. In this case the conclusion was that of the cheapest motherboards sold for the last few years that had any 3D support, there was almost nothing apart from a small number of esoteric cards that were restricted to a single texture. Any effort on supporting this environment was best delayed to a future time. Additionally, as part of studying this information, I was able to determine a number of other assumptions that I could make regarding the capabilities of typical video cards out there. This would have saved me considerable time had I researched this earlier, and it saved me considerable time afterward as I could make a number of educated assumptions about the sort of hardware I could expect to see.

Anyway, I just wanted to share my experience in this regard. Perhaps the suggestion will be more useful to others, and perhaps it might end up being more useful to you at a later stage of development. All the best in any case.

That is great info, actually ^^ thanks for sharing. I've never noticed the button "CLICK FOR MORE INFO" where I can see where my graphic card fits.


I decided to change how the content of my game engine is managed. I was already using a memory pool, allocating and reallocating in a contiguous memory space, however, the reallocation could cause problems of invalid pointers. I changed that by putting a limit for every kind of content in the game, like this:

Code:

struct cprogram {
	...
	ctexture textures[CONFIG_MAX_TEXTURES];
	cframebuffer framebuffers[CONFIG_MAX_FRAMEBUFFERS];
	cshader shaders[CONFIG_MAX_SHADERS];
	crenderer renderers[CONFIG_MAX_RENDERERS];
	...
};

When i do `new_texture()`, it will simply search for one of the free `slots` in that pool. The user of the engine is responsible to change the macro `CONFIG_MAX_*` in development-time to suit the needs. Safety++ Performance++

[ferreiradaselva]

My renderer for 2D quads is usable. It accepts only one texture for now (enough for me, because I'm using a texture atlas), but I will update to accept multiple texture (and filter by texture) later. Also, projection matrix is now sent to the shader.



Aaaaaaand, the input system is very nice, inspired by the godot input system. In the initialization I assign inputs with a name:

Code:

add_key_input("p1_up", KEY_UP);
add_key_input("p1_up", KEY_I);
add_key_input("p1_down", KEY_DOWN);
add_key_input("p1_down", KEY_K);
add_key_input("p1_left", KEY_LEFT);
add_key_input("p1_left", KEY_J);
add_key_input("p1_right", KEY_RIGHT);
add_key_input("p1_right", KEY_L);

Then in the update I can query using only that name (note above that I can have different buttons for the same action):

Code:

if (get_input("p1_up")) {
    printf("move up\n");
}

easier for programming, and easier when I have to implement the menu for controller configuration.

[cherry_monster]

That's a cute test image

For sprite rendering, I wouldn't worry too much - just bear in mind not to do anything too stupid and you'll be good until you get into the scale of thousands of sprites at once, and even then that's for low end hardware. Even looking at integrated graphics now, the limitation you'll hit is on the CPU side if you're doing something like multiplying your MVP matrix every update or something

[oahda]

Build tools working for Mac and Emscripten now!

Takes some time now that I have to formalise more properly how to deal with it, but it's still mostly copypasting premake/cmake instructions and build scripts from my previous test, just cleaning it up a bit and making sure to output error messages wherever something can go wrong. Just gotta add the other four systems back. c:



I'm also bootstrapping the Karhu library itself on top of its own build tools now, compiling it the same way using them!

Also tried using one of those fancy planning tools to see if it would increase my productivity. So far, so good. It's nice to have lists at least.

[qMopey]

@felipe may I ask why there is a mapping of strings to constants? Looks pretty curious! Usually I just see mappings of ints to ints for inputs, so I was wondering what you were thinking there.

[ferreiradaselva]

That's a cute test image

For sprite rendering, I wouldn't worry too much - just bear in mind not to do anything too stupid and you'll be good until you get into the scale of thousands of sprites at once, and even then that's for low end hardware. Even looking at integrated graphics now, the limitation you'll hit is on the CPU side if you're doing something like multiplying your MVP matrix every update or something

Thanks, it was a logo/sprite I made for my previous engine experiment

Build tools working for Mac and Emscripten now!

Also tried using one of those fancy planning tools to see if it would increase my productivity. So far, so good. It's nice to have lists at least.

Wohooo! Emscripten is on my plans too. Converting all the OpenGL stuff will probably be annoying, tho.

Is this planning tool like kanban? If it is, you should check the "Projects" tab on github. I started using it, and really helps!

@felipe may I ask why there is a mapping of strings to constants? Looks pretty curious! Usually I just see mappings of ints to ints for inputs, so I was wondering what you were thinking there.

Nothing special, mapping to ints would be faster for querying than comparing (hash of) strings, but I would have to use some readable macro like `P1_LEFT` and include the header containing those macros in every source that would need them.

I will, btw, make some tests with your collision library soon!

[oahda]

Wohooo! Emscripten is on my plans too. Converting all the OpenGL stuff will probably be annoying, tho.

The support is more decent than I thought, actually! Even when I specify GLES2 (whatever that means when it's actually WebGL which is it's own subset if I've understood correctly?) it supports more stuff than, say, an Android device on Jellybean with strict GLES2 does. And there's actually a "GLES3 emulation" flag that I haven't tried yet.

Is this planning tool like kanban? If it is, you should check the "Projects" tab on github. I started using it, and really helps!

Ended up with hacknplan, which is tailored specifically to games, so it already has categories like programming and art built-in, which is nice. My only annoyance right now is that they don't support 24-hour time format (whether midnight is 12 AM or PM seems not to be entirely agreed upon‽), but I tweeted them and it's on the way. c:

[JWki]

hacknplan looks nifty I like that it has github integration.

[J-Snake]

Working on a non shader effect for a little game. I want to restrict myself to the sdl renderer only for certain 2D games. But I am quite happy that you can still achieve cool effects without shaders. I am figuring out a suiting shockwave effect for what you can see in the clip. Wonder how you like the current one, if you like to drop a glance:

[oahda]

That's nice! Would've definitely assumed that to be shader if I hadn't known.

[J-Snake]

If you think about it, SDL_RenderCopy() is all you need;) You can fill up the screen by sliced rects without much impact on performance since the bottleneck here is the fillrate of the gpu, not the number of SDL_RenderCopy() calls. I can go through multiple render passes that way on a regular integrated laptop gpu, 60fps no problem.

I actually updated the clip with a bit more spacing between the initial shockwaves. One way to look at it is that the impact-energy is carried out to the sides in form of a wave when boxes come crushing down. So I think it is more appropriate now.

[qMopey]

Pretty cool. Reminds me of an article in Game Engine Gems, named something like "2D Magic". It talked about setting up a full-screen mesh and rendering everything in the mesh. The mesh was a regular grid. Then the vertices can be colored or moved around for full-screen effects, like balls of light/color, or warping effects. Pretty much simulated a vertex shader.

IIRC the point of the article was to get cool fx on much older iOS devices, before they were as powerful as today. Pretty similar to SDL surface stuff, since I heard that 2D SDL rendering was mainly intended to allow easy porting of much older programs. You know like that really old Windows stuff that would draw pixels with dib sections, or whatever it was back then.

[ferreiradaselva]

Got z-ordering working (using opengl depth).

I love software rendering. Not as faster as GPU rendering, but way cooler! Yeah, drawing with DIB was a headache. I did that kinda of thing when I was starting programming. But, my favorite thing was mode 13h, rendering with VGA! I didn't do that much, because the thing was getting unused soon after I started programming (something around 2002). Still, I like the idea of software rendering, I'm even working on a patch for GLFW to allow no client API (no OpenGL/Vulkan backend) to be loaded and use a proxy buffer to render on the window!

Edit:

I'm thinking about starting a blog with github pages, focusing on C programming and maybe some biology (bc I'm a biologist working with bioinformatics).

[JWki]

Got z-ordering working (using opengl depth).

I love software rendering. Not as faster as GPU rendering, but way cooler! Yeah, drawing with DIB was a headache. I did that kinda of thing when I was starting programming. But, my favorite thing was mode 13h, rendering with VGA! I didn't do that much, because the thing was getting unused soon after I started programming (something around 2002). Still, I like the idea of software rendering, I'm even working on a patch for GLFW to allow no client API (no OpenGL/Vulkan backend) to be loaded and use a proxy buffer to render on the window!

Edit:

I'm thinking about starting a blog with github pages, focusing on C programming and maybe some biology (bc I'm a biologist working with bioinformatics).

Glfw already allows to create a window with no client api btw.

[ferreiradaselva]

I should've been more clear. Even with the GLFW_NO_API hint, it will still have dependencies with OpenGL/Vulkan. The idea is to give an option to build without them (and provide a proxy buffer for software rendering).

[Schrompf]

Strange. I patched NO_API into GLFW, too. Back in 2012, that is. Things probably have moved since then.

[ferreiradaselva]

Strange. I patched NO_API into GLFW, too. Back in 2012, that is. Things probably have moved since then.

Oh, the NO_API flag is still there. It's just that GLFW link to OpenGL OR Vulkan, even if you don't use any of them.

[JWki]

I should've been more clear. Even with the GLFW_NO_API hint, it will still have dependencies with OpenGL/Vulkan. The idea is to give an option to build without them (and provide a proxy buffer for software rendering).

Ah yeah that's a good point.

[J-Snake]

Pretty similar to SDL surface stuff, since I heard that 2D SDL rendering was mainly intended to allow easy porting of much older programs.

That's correct. You can see that their render functions are oriented around blitting, that's why they take ints instead of floats, which would be more suitable for rendering computations. For example if you naively implement a zoom function it will stutter, just because of ints. However there is a workaround for this and other problems but it requires some technical dedication. I actually went down this route since I want a capable 2D engine based on sdl renderer alone. As for the zoom problem, sdl has an internal scale variable. You can exploit it by doing your transformations in an enlarged space (let's say 100 times the normal space) and then you simply set the scale variable to 1.0/100, numerical problem solved and zooming gets potentially 100 times smoother. Then there is the camera. I do camera rotations/translations/zooming per sprite basis. Sounds like an overkill but this approach is actually more efficient and flexible under the given constraints. For example if you would simply take the scene texture and rotate it around there could still be elements in the background which you possibly don't want to rotate. That would already imply the need for multiple render passes since you have to separate the layers and cannot just use one. Since per sprite operations can enable you to work like with a 3D camera all the camera transformations can be composed into one single texture. For example if an object in the background isn't supposed to scroll and zoom you set its scroll/zoom-factor to 0.0, so it would correspond to an object infinitely far away in 3D space (you just cheated in its supposed projected size but that's perfectly valid since infinity/infinity can be any number;) ).