Elysian Shadows

Hi everyone, I am new developing a 2D game with C++/SDL for Linux, but not programming.
The target hardware where the game will be played isn't powerful, 256RAM at most. So, openGL is out of discussion.

I have sheet srpite file, it contains the character movements, and several files for the backround and other sprite files to put on a layered fashion way.

When the applications keeps simple, the character/sprite can jump, it moves to left, right, up and down, etc. It works fine.
By simple I mean: one background and the sheet sprite.

According I add more screens and sprite it desceases the speed in a unplaying way.
I think I did a bad choice: I upload the sprite sheet at the begining and the rest of the screen are loaded on demand from disk, but I think is very 'CPU expensive'.
I plan to upload more than one screen/file to memory and switch between them on demand. Is this the correct manner?.

I'll chek the bit format of the screen to be the correct SDL_Displayformat before bliting, and etc.

Any suggestion for the best strategy? or the format file to work with?

Thanks

Kovi

kovicic wrote:Hi everyone, I am new developing a 2D game with C++/SDL for Linux, but not programming.
The target hardware where the game will be played isn't powerful, 256RAM at most. So, openGL is out of discussion.

first 2 sentences in and i see some problems, first you could elaborate on the hardware your using and by 256 ram what does that mean? it could mean 256 bits of ram, it could be 256 bytes,kilobytes,megabytes,gigabytes,etc, to sum it up could you be a little more specific and share some more details :S?

Light-Dark wrote: first 2 sentences in and i see some problems, first you could elaborate on the hardware your using and by 256 ram what does that mean? it could mean 256 bits of ram, it could be 256 bytes,kilobytes,megabytes,gigabytes,etc, to sum it up could you be a little more specific and share some more details :S?

Considering it's Linux, 256 KB and 256 GB are both ridiculously unreasonable assumptions, leaving 256MB as the only one which makes sense. I honestly don't see how that was so complicated to figure out.

dandymcgee wrote:

Light-Dark wrote: first 2 sentences in and i see some problems, first you could elaborate on the hardware your using and by 256 ram what does that mean? it could mean 256 bits of ram, it could be 256 bytes,kilobytes,megabytes,gigabytes,etc, to sum it up could you be a little more specific and share some more details :S?

Considering it's Linux, 256 KB and 256 GB are both ridiculously unreasonable assumptions, leaving 256MB as the only one which makes sense. I honestly don't see how that was so complicated to figure out.

just pointing out that it could be a little more specific thats all.

I am not sure how well SDL works with .jpeg but when it comes to the file format .jpeg will be the least intense on the CPU. What kind of sprites are these 16-bit? If so I think if you upload it as a jpg it should look fine. I for one have never had a problem loading all of the sprite sheets at the beginning. I really don't think its the art check the coding for memory leaks and what not.

jakobnator wrote:I am not sure how well SDL works with .jpeg but when it comes to the file format .jpeg will be the least intense on the CPU. What kind of sprites are these 16-bit? If so I think if you upload it as a jpg it should look fine. The sprite sheets I really have never had a problem loading all of the sprite sheets at the beginning. I really don't think its the art check your coding, most machines should handle a 2-D computer game.

Seriously? Is .jpeg more efficient than .bmp formats?
And yes, modern computers can easily handle a 2D game, but I guess they are making a game for a somewhat old/limited system.

superLED wrote:

jakobnator wrote:I am not sure how well SDL works with .jpeg but when it comes to the file format .jpeg will be the least intense on the CPU. What kind of sprites are these 16-bit? If so I think if you upload it as a jpg it should look fine. The sprite sheets I really have never had a problem loading all of the sprite sheets at the beginning. I really don't think its the art check your coding, most machines should handle a 2-D computer game.

Seriously? Is .jpeg more efficient than .bmp formats?
And yes, modern computers can easily handle a 2D game, but I guess they are making a game for a somewhat old/limited system.

i use png format, does sdl provide any documentation to which format is less CPU intesitve or is this from personal experince?

Light-Dark wrote:

superLED wrote:

jakobnator wrote:I am not sure how well SDL works with .jpeg but when it comes to the file format .jpeg will be the least intense on the CPU. What kind of sprites are these 16-bit? If so I think if you upload it as a jpg it should look fine. The sprite sheets I really have never had a problem loading all of the sprite sheets at the beginning. I really don't think its the art check your coding, most machines should handle a 2-D computer game.

Seriously? Is .jpeg more efficient than .bmp formats?
And yes, modern computers can easily handle a 2D game, but I guess they are making a game for a somewhat old/limited system.

i use png format, does sdl provide any documentation to which format is less CPU intesitve or is this from personal experince?

Png is an easy format to work with. It has an Alpha Channel, compressed somewhere between .jpg and .bmp (correct me if I'm wrong). With the Alpha Channel, you don't need to paint pink color on the parts that should not be drawn. That way, you can also use different values of Alpha, like a fading-effect or similar.

.bmp files are more compressed and space friendly, but the quality (the amount of colors) are not that good. Old computers was stricted to this format because it took up so little space.
I don't think .jpg formats have an Alpha Channel. Maybe some 'versions' but it's not the standard.
And I also think .png is the standard format on the web as well, due to its decent quality and the little space it takes, and the Alpha Channel.

This may not be 100% correct, and it may be outdated.

Some versions of .bmp have an optional alpha channel, not sure if you can use it with SDL.

jakobnator wrote:Some versions of .bmp have an optional alpha channel, not sure if you can use it with SDL.

SDL can do alpha blending, but it's very slow about it. This is primarily because SDL cannot take advantage of optimized array-copying techniques (memcpy is pretty good), and has to do extra processing for every pixel it blits.