SpritesMind.Net

So I don't end up flooding this forum with individual threads per question, I figured it'd be better to add them all to one general thread as I learn.

I've been experimenting with different methods of loading the map on the fly as the player moves (for maps bigger than the VDP limit), and I had the idea of using a 2D array of pointers to palettes PAL0-3, so I could use all palettes on a single plane with VDP_setMapEx() pulling the palette from the array based on the camera tile coordinates. The problem I'm having is creating the pointers, I guess my understanding of the Palette structure is wrong?

I declare the pointer with And assign the pointer with Error: It seems to accept my declaration of the pointer, but not my assignment of the address. My understanding was that the palette structure was just a u16 array, so it should have an address in memory, no? Is it possible to create a pointer to a palette?

If you don’t give us the definition on PAL1, there is no way of telling where is the mistake other than guessing.

billybob884 wrote: Sat Oct 27, 2018 4:52 am so I could use all palettes on a single plane

What most games do is break up palettes like this:
1 pal for main characters, a few foes, the hud and perhaps things like explosions and similar effects.
1 pal for foes, and foes’ shoots.
1 pal for each of the two backgrounds.

Obviously there all type of variations. The problem with sharing one palette with more than one type of graphical object is that you get trapped when is time to change it, so you end up with the situation of being unable to change palette colors at all.

Another alternative could be having all 61 colors fixed from the beginning, is something I would like to experiment someday, but my guess is that it would work terribly for the backgrounds/planes since will be no continuity in them when changing palette.

And yes, so few palettes is the weak point of the system.

Hi, thanks for the reply! So I don't fully understand how SGDK handles the palettes (PAL0 thru PAL3), they seem to come pre-declared? Take the moon tutorial for example: Data is loaded to PAL1, but nowhere is PAL1 actually declared, it just seems to exist.

As for distributing palettes, I understand most games use one per plane, one for sprites, etc, this was just an experiment to see if I could do it. Maybe being able to use just two palettes on a plane would be useful, or maybe it's a waste, I'm so early in the design/experiment stage who knows.

PAL1 isn't a palette structure, it's a palette number for choosing one of the four palettes in the hardware. You have to make your own palette structure with your own name.

Hah I see, this is a silly mistake on my part. I just spotted the constant definitions for "PAL1" (and the others) in vdp.h, so they're not actual palette structures that need a pointer. All I would need for this experiment is a u16 array of numbers 0-3. Thank you!

A palette struct is defined in vdp_pal.h and looks like this
It's two unsigned shorts and a pointer. The index is the starting palette entry to set (0 to 15), the length is the number of palette entries to set (1 to 16), and the pointer is your palette data (an array of unsigned shorts with the BGR color values). This allows you to set as few as 1 color, or as many as 16 (the full palette).

No, I understand the palette structure. My mistake was assuming the "PAL1" used for the "pal" parameter of VDP_setPalette() was a full palette structure; I didn't realize PAL1 was just a defined constant (u16) 1.

My experiment was going to be passing the "pal" parameter a value from a 2D array, where the array entries corresponds to x/y locations of the tile map, hence why I was trying to fill the array with pointers to the supposed PAL1 "palette structure" (again, I understand now that it's not a palette structure). Now that I realize PAL1 is a defined constant, the array would just have to be (u16) numbers 0-3.

So I'm experimenting with using very large scrolling maps. I've got a rough system in place to load the map on the fly as the player moves, but the problem I encountered is the limit of how large of a map can be unpacked to RAM (some trial & error testing put the approximate maximum at two maps (FG & BG) measuring 100x132 tiles).

I found suggested in another thread to leave very large maps uncompressed in ROM and just load directly without decompressing, but what I'm wondering is how much space is the compression actually saving? What types of compression ratios do the different compression types (listed in rescomp) typically achieve?

For reference:

It will depend on the map itself.
For example, imagine that we are using a platform game like Mario or Sonic, first get rid of the background, and then you will find that most of the map is empty space, the same metatile or tile. The compression will be highly effective because it will pack all these repetitions.

Another thing, use metatiles instead of tiles. Those are packs of 2x2 graphical tiles AND 2x2 collision tiles. Could be any other size but 2x2 usually works well.

There is a lot to discover around these matters, so keep digging!

SGDK doesn't really have MAP storage strategy right now, it's something i plan to add but that requires some work (both with the tools and methods to handle that). The best you can do currently is to cut your level into several smaller maps which fit in memory when they are unpacked, or, as Miquel suggested, develop your own map / compression strategy.

I have a rough map-loading strategy that works well enough (for my tests at least), I was just wondering roughly what kind of efficiency I might expect for rescomp's "IMAGE" structure. I understand that it will be map-dependant, but rough order of magnitude, are we talking 5-10%? 25-50%? 10-90%?

My game design plan is very up in the air, but I don't plan on having many maps this large. This is more for my edification than anything else.

When you enable compression for your IMAGE resource in rescomp, it will compress both the tiles data and the tilemap.
If you choose BEST compression, you can expect about 40-50% compression ratio on the tiles / tilemap data but then you need to unpack data at level start as the compression is too slow to be done "in real time".
If you choose FAST compression, you can expect about 60-70% compression ration but it's much faster so it can be used almost in real time (at least you can do it for sprites).
These numbers are very likely to change depending your data of course, very detailed graphics are likely to compress less while basic flatten colored graphics will compress better obviously.

billybob884 wrote: Mon Nov 19, 2018 11:03 pm I was just wondering roughly what kind of efficiency I might expect

What kind of game are you building?
How many different many tiles/metatiles are you expecting grouping per functionality? For example, it will be solid, air and leaders.
Of each functionality, there will be duplicates? For example, imagine you are doing the grass tile/metatile, it will be more than one grass tile/metalitle?
How are you going to decompress it? I mean by column, by screen or the entire map at once (or any other you may say).

Stef, thanks for the ballpark numbers.

Miquel, my (very) tentative plan is a top-down RPG, so functionally there will only be maybe four or so tile types (non-solid, solid, water, and maybe one-way blocks? Not sure yet), but aesthetically several tiles per category (very rough order of magnitude, maybe 20-90?).

As for map loading/decompression, my experimental system thus far decompresses the level's plane A/B maps to RAM (if the level is small enough), or if the level is too large, to decompress one map to RAM and then leave the other uncompressed in ROM. Probably not the most efficient way of doing it, but at least for now it works.

You should expect compression ratios a bit better than the ones Stef give to you for the plane B, but for plane A you must see a really huge improvement since most of it while be the empty tile, anything greater in average than 25% should be extremely surprising.

Anyway, research/planing should be your priority.