New sprite and font sheet idea for Lux.

[Asimov]

Hi Lux,

This is an idea for a different slant on your program.

I have watched both tutorials 20 and 21 for loading BMPs and Font sheets, but I have had an idea for a modificaation or spin off to your program.

Ok it is nice to load bmps or sprites from a file, but it means you have to have image files loose in a folder or in the root folder. Sometimes this is ok, but sometimes you would rather have you images in the exe itself. One method might be to once load your bmps is to save them to some kind of resource file which can be merged into the exe, but I have a different solution.

Ok here it is. Say I had a font sheet with all my characters. If I put them in your current program it would read them all in line by line. However say I knew that each character was 8 by 8 it would be really cool, if your program instead of reading right across the characters sheet was to save out the putpixel lines in 8 by 8 or 16 by 16 or 32 by 32 blocks depending on the size of the font. I hope I haven't lost you here.

Anyway you would end up with a text file where say I had an 8 by 8 font. The first 8 lines would be say a space, then the next 8 lines would be the next character and so on.

You could also use this system for animated sprites. You lux program could also load in a sprite sheet too.

The beauty of this is that you can make exe's with no need for external files.

What do you think Lux?
I don't think the modification would be hard to do. Also you would have to know the dimensions of your characters or sprites and this way you would type in say 8 by 8 or 32 by 32 if you know what I mean. You could call it something like the Lux spriteloader program or something LOL.

Asimov

[ghilllie]

I don't think that would be advisable.
Games with tons of textures should always make a separate directory folder for the textures
because if you merged them in your executable then your executable file will be exaggerated in size. executable is normally just a trigger to execute your program and its normally reaching only in kilobytes not more IMO.

not sure though what exactly executable can do more than just a trigger...

[LuX]

Maybe if I find some time and motivation I could try to do something like this. Or maybe even that you could load a list of images and it will just scan them all.

I don't think that would be advisable.
Games with tons of textures should always make a separate directory folder for the textures
because if you merged them in your executable then your executable file will be exaggerated in size.

Text in general doesn't take much space. So even if its larger, it's still not that huge. And in the case what asimov want's to do this should work good enough. After all loading the images from a source has so upload the memory to the buffers anyway so if anything, it should make the program start faster, when not debugging.

What I would do is load the images on a sprite database created in c++ and just use those as a source. But I'm not sure how I can "combine" and access CLR forms.

[LuX]

Anyways... Here's something I made ages ago in VB. A game I never finished, maybe I'll later recreate it in c++. Spent tons of hours making it, the game has a LOT of items and stuff, about 300 different items to be found or crafted. Just reminded me when ghillie talked about a game with a lot of images : -)

[Asimov]

Hi Ghillie,

If I was making a game with thousands of images yes I would put them in a directlory or folder, but my game will have about 6 images at most.

My game will have a background screeen, and about 5 or 6 different sprites, so for this game I would rather have the images in the exe itself.

Also the font sheet would be rather small, so I am thinking it would be best to keep the font sheet in the exe, at the very least. Even if some idiot deletes your image folder, at least some text can come up and say that it cannot find it's files.

Also had another cool idea, that once you had all your image files as putpixel commands you could output them into a binary file. which means all your images for your game could be one single data file loaded in. And you could make it unreadable as an image. Lots of fun for binary writing LOL.

@Lux: Looks like a cool game idea. Would be well worth doing it in C++ for the speed increase. Also reminds me of top down version of minecraft heh heh.

Asimov

[chili]

Generally speaking, a very small number of small sprites would be marginally faster as compiled sprites rather than pixel arrays (surfaces), however in most cases it loading the sprites into arrays from files would be faster. The reason lies in the way the CPU caches instructions. Compiled sprites make a huge amount of instuction code which will blow your CPU instruction cache lines and hit you with a big slowdown.