SpritesMind.Net

Sik wrote: ↑

Wed Feb 14, 2018 11:31 pm

Well, sprite limits are your enemy here so don't try to do it on wide areas...

Yeah, and I'm starting to notice that the 64k RAM is not much either...
I would really like to make a copy of the stage tile map, so I can manipulate it. But that will waste a ton of RAM, for instance.
The sprite unpack buffer is taking quite a bit of chunk as well, so I might need to go with non-packed sprites.

Sik wrote: ↑

Wed Feb 14, 2018 5:14 pm

It involves exploiting layer priorities and sprite ordering: sprites are put on top of each other strictly by order (ignoring the priority bit), and then the end result is mixed with the other two layers (only here the priority bit takes place). This means that a low priority sprite can cover a high priority one, and if there was plane A/B with high priority in the same place, you effectively create a cutout (which can be exploited to make silhouette effects).

I suppose the idea is to separate a image into different layers with the objective of finding the maximum number of repeated tiles and thus using less video memory. Correct?

But I don't like the idea of using all video resources (A & B planes, sprites) to show a single picture since this disables you to show other things, like a menu or a background.

mix256 wrote: ↑

Wed Feb 14, 2018 6:42 pm

Will start experimenting with this masking technique right away. Thanks!

The golden rule for How To Finish A Game is to avoid anything that doesn't affect playability at least until you have a playable demo of you entire game. Just sharing a bit of experience.

mix256 wrote: ↑

Thu Feb 15, 2018 8:39 am

Yeah, and I'm starting to notice that the 64k RAM is not much either...

There is not enough video memory to display a full screen fully detailed image on screen, but there is a bit too much when is time to develop a game all by your self, knowing that you will update some part of it in loading times between levels.

Miquel wrote: ↑

Thu Feb 15, 2018 2:04 pm

mix256 wrote: ↑

Thu Feb 15, 2018 8:39 am

Yeah, and I'm starting to notice that the 64k RAM is not much either...

There is not enough video memory to display a full screen fully detailed image on screen, but there is a bit too much when is time to develop a game all by your self, knowing that you will update some part of it in loading times between levels.

Sorry, but I don't understand what you're trying to say here.
What I want to do is to remove tiles (at explosions, or when opening doors etc) from the stage tile map. So I would like to have a buffer in RAM for this. But, as it is now, it would require 8K of RAM. Space I don't have. So I will most likely need to create a list of all the places where there is a change to the tile map and walk through those when checking for background-collision and what not.
And seeing that the game is only moving to the right, at the moment, I guess there is smarter ways to handle this. But I might want to make stages that you can backtrack in. Don't know yet.

And here we are, we've finally arrived, at sunset, in Rome. Or maybe Athens?

mix256 wrote: ↑

Thu Feb 15, 2018 4:27 pm

Miquel wrote: ↑

Thu Feb 15, 2018 2:04 pm

mix256 wrote: ↑

Thu Feb 15, 2018 8:39 am

Yeah, and I'm starting to notice that the 64k RAM is not much either...

There is not enough video memory to display a full screen fully detailed image on screen, but there is a bit too much when is time to develop a game all by your self, knowing that you will update some part of it in loading times between levels.

Sorry, but I don't understand what you're trying to say here.

Don't be deceived by the apparent lack of video memory, there is plenty of work ahead.
For example, you will discover a great deal of tricks to overcome this limitation.

Miquel wrote: ↑

Fri Feb 16, 2018 2:19 pm

mix256 wrote: ↑

Thu Feb 15, 2018 4:27 pm

Miquel wrote: ↑

Thu Feb 15, 2018 2:04 pm

There is not enough video memory to display a full screen fully detailed image on screen, but there is a bit too much when is time to develop a game all by your self, knowing that you will update some part of it in loading times between levels.

Sorry, but I don't understand what you're trying to say here.

Don't be deceived by the apparent lack of video memory, there is plenty of work ahead.
For example, you will discover a great deal of tricks to overcome this limitation.

It's not the VRAM I have a problem with, it's the "normal" RAM.
Stef and SGDK is handling the VRAM just fine, thankfully.

Oh! you meant 68k memory...

Most people store the level information on ROM and use 2x2 tile/collision structures to avoid memory problems.

Myself I always use a 32KB map on RAM and directly "paint" on it to build or modify the current level. I also use the 2x2 tile/collision structures. No map on ROM, and that saves a lot of it.

In my case, sprite list takes about 10-15KB and I reserve a 4/8KB buffer for decompression and save/load data. Spawn buffer, event buffer, a few more system buffers and that's pretty much it.

And was thinking I was using much more memory that average MD programmer. So in what are you using it to be in such a need of it?

Miquel wrote: ↑

Fri Feb 16, 2018 3:32 pm

So in what are you using it to be in such a need of it?

If I do MEM_getFree(), as it is now, it says 11K left and if I do MEM_getAllocated(), it says 35K. So someone has stolen mem from me! Thieves!
Sprite unpack buffer is probably about 24K.
My object structures is about 14K.
The rest is a mystery. Some tables in SGDK, maybe?

Everything that could be updated on vblank should be buffered:
- Hardware sprite list
- 1 o 2 copies of the full palette
- both scroll arrays
- 1 (or a few) rows or cols of tiles
- A buffer to update tiles.

(A good design is one in which you never access vdp on main loop, except perhaps on menus and such special occasions)

Plus a few system variables, but that's 4/8KB top. Ask on SGDK subforum.

Argh, wine cant handle rescomp so I won't be doing any actual progress this week. On a small vacation with just the portable crap mac.
At least I can continue to draw, which is the most time consuming.

mix256> Are you using the sprite engine ? If it's the case, how did you initialized it ? Sprite engine consume some memory... Also i don't understand if you use your own sprite unpack buffer or if you speak about the Sprite Engine one ? As the sprite engine can have one And you may use it so you don't need to deal with that on your side. About memory footprint, i guess SGDK consume about 6 KB of memory at minimum..

Wait, I thought rescomp was written in Java? May as well just use a native Java VM. Or is that particular tool not using it?

Stef wrote: ↑

Sun Feb 18, 2018 8:23 pm

mix256> Are you using the sprite engine ? If it's the case, how did you initialized it ? Sprite engine consume some memory... Also i don't understand if you use your own sprite unpack buffer or if you speak about the Sprite Engine one ? As the sprite engine can have one And you may use it so you don't need to deal with that on your side. About memory footprint, i guess SGDK consume about 6 KB of memory at minimum..

Yeah, SPR_init(127, 768, 768);
That last 768 is about 24K, right?

Sik wrote: ↑

Sun Feb 18, 2018 9:05 pm

Wait, I thought rescomp was written in Java? May as well just use a native Java VM. Or is that particular tool not using it?

It's an exe. But the source is in there so I guess I could try to compile it for the mac.
My own tools are all made in java, though.

Yeah, 768 tiles so 24 KB, to be honest that is a lot ! I can understand you reserve 768 tiles for sprite in VRAM but you probably don't need to reserve as much for the unpack buffer (it's used to unpack sprite tiles between 2 SPR_update() calls) as normally you will never update 768 tiles at once !

Also rescomp is wrote in C, trying to use standard methods so it could be compiled on any platform. Later i will probably switch to java though, much ore simpler for me :p