Game question

I am creating a game (engine) with SDL 2 using C and I am planing to have a scheme dialect to extend it in the future
here is my question, let's say I have N textures that I want to be rendered, should I have them in a list and render them every time something happens to the event loop? The other programmer I am working about is against the idea of having every texture in a list and believes that we should have them normaly in the code like variables, what to do?
another question is how to access other objects by some functions, for example I want every time someone presses the UP button to change the player position but in that case I should a: have the player variable as global or b: pass it in that function, should I have another list or something (like a db) for every object or something?
I have no idea on how to work with game stuff

typical design is to load textures in as assets, have game objects (tiles, sprites) reference them with pointers or offsets. stored objects might reference them by name, this should be converted to pointer or offset when loaded into memory.

advice: read up on the doom wad format. clean, fast, compact asset storage.

iirc SDL presumes you will issue redraw for the entire screen every frame and reserves the right to trash your buffers after they've been blitted.

it's best if you can avoid globals. but fine for prototyping and for small games. when making a big game out of a small one you will usually need to turn some or all globals into stack objects and pass them around.

you forgot to ask a question about scheme. collect every frame.

Store them with differential encoding in an endotensor buffer. It's both faster and uses less memory at the cost of slightly increasing compile time.

>>2
Interesting, thanks.

>>2-3
Thank you both very much

typical design is to load textures in as assets, have game objects (tiles, sprites) reference them with pointers or offsets. stored objects might reference them by name, this should be converted to pointer or offset when loaded into memory.

if I understand correctly you need code to save, modify, get values and unload objects while they are stored in a list/tree or something
I was thinking of having functions like these (C-like code)
bool objectSet (tree, const char *name, void *data);
void *objectGet (tree, const char *name);

iirc SDL presumes you will issue redraw for the entire screen every frame and reserves the right to trash your buffers after they've been blitted.

I am using SDL2, is this still a issue?

and people say that /g/ is better than /prog/... pfff

>>5
I can't quite tell how those functions are meant to be used, but I'll elaborate:

if you have few enough or small enough assets that you can keep all of them loaded for a given level/area then it's easiest to load/unload them all for each level/area. you can put the whole level into an arena and deallocate the arena on unload. added bonus: reduced memory fragmentation.

if not, you probably want a master list of all assets in the area, with some function that will update the pointers on load, and some way of marking them as invalid on unload. you will also want a good way to determine in advance what needs to be loaded so it can be retrieved from disk by the time its needed. it's usually pretty easy in 2d scrollers, but less often necessary.

I think sdl2 probably has the same behaviour. it's not a drawback per se. they exploit it to optimize sdl. the good news is you don't have to worry about calculating what needs redraw, just draw every frame afresh. this keeps the drawing code regular, since every frame is drawn in the same way.

>>3
Stop trolling.

https://www.google.com/search?&channel=fs&q=endotensor+buffer&ie=utf-8&oe=utf-8

>>7
Thank you kind anon, very much

>>9
good luck

>>8
Try going to a fucking library and reading some actual academic papers you blithering retard. Things don't cease existing just because your favorite faggot blogger didn't write a tutorial about them laced with enough keywords to make the first page of google.

>>11
Toilet scrubbing pseudo-intellectual cretinoid stackboi go bang a million autistic niggers.

>>11
No, I'm pretty sure ``endotensor'' is a made up /prog/ joke. Care to prove me wrong?

SDL2 is a piece of shit. It broke compatibility and everything became more complex and bloated. SDL_CreateWindow got a fuckload of parameters people don't care about, when they want to just push some pixels on the screen as quickly as possible. I loved SDL, because had no matrices and orthogonal projectors and that other bullshit, required in other graphics packages. Now I have to seek some other solution and invent it myself.

Alternative is http://alleg.sourceforge.net but it is even more bloated and always runs through OpenGL, meaning that on screen pixel values ain't the same you put into frame buffer, because GPU does floating-point crap on them.

>>14
http://www.piston.rs/

(Uses SDL2 but does not expose much of it.)

>>16

Python

no thanks.

Back in the days drawing graphics on screen was as easy as "((char*)0xA0000)[(y<<width)+x] = color". The joy of instant gratification! Today everything requires studying through boring manuals and getting your way through roadblocks of useless features. Truly the less is more.

>>17
What's your problem? I said nothing even related to Python.

>>18
You can still do that. Most cards still support VESA.

>>14
The fact that they use recerved keywords (_SOMETHING_H) as guards or they use int instead of size_t makes me wannting to kill them
fucking stackboys

>>13
an endotensor is just a field morphism, chimpface.

>>22
http://thatsmathematics.com/mathgen/