That article is amazingly wrong, holy shit. I should go in and fix it probably. It's 32 sprites per line, 128 total, 8x8. I obviously use them in bunches to make larger sprites.
That is a good idea as many of us never used the machine and would not say "hang on..".
It's a traditional line-buffer VDP design, so it only renders a line at a time, so it just drops any sprites beyond 32 each line. My multiplexing scheme handles this as well, but it's nothing unique. It's the same technique used on NES a lot to get around that platform's stingy 8 sprite limit. Essentially every even frame I go from the front of the list forward (which keeps everything in proper priority), and every odd frame I go from the end of each priority's list backwards. This way, two overlapping sprites in the same priority will flicker, and when you lose sprites from going over the total count or the line count, it's not going to go away forever.
I see. Yes, it reminds me of the Megadrive's VDP that effects a priority based on the order.
So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?
No, those are just highest priority sprites, so they'll always be on top even through the multiplex scheme.
Yes, I use the same system myself so the last is always the player's ship and its bullets and little-buddies/helpers
http://www.nintendolife.com/news/2014/0 ... wonderswan
Yes, it looks like the WS has 256Mbit = 8MB system RAM and 512KB VRAM - not bad.
I have no idea where you got those numbers, as they're faker than George Washington's teeth. WSC has 64KB internal RAM, which is shared for the sprite table, tiles, tilemaps, palettes, and sound wavetable. I opted to not use the IRAM for general RAM, and am instead using 64KB of on-cart SRAM instead, just using the IRAM for system memory.
"and system RAM was increased to 256 Mbit" - Some porkies..
Ok, it is the same as the MD with 64KB of RAM but shared with the Z80 and 68K - I call it Work-RAM.
Yes, it makes sense to use the ROM as you get more of it and as many things are 'scripted' for a Shmup it does not need to be modified so it is wasteful to make it taking up your WRAM - makes sense.
How much memory does the event-table for your enemies occupy?
Also, have you compressed any of the event-table entry data or it is raw and expanded?
Not sure what you mean, that's not how my engine works. It's just got an abstract concept of a "task" (up to 96) with a callback that runs every frame and associated work data (up to 124 bytes). In total the task array is 12KB.
I get you - a set of tasks each with a TCB (task control block).
So you callback is your tasks that acts as a scheduler or task-selector and swaps in and out your tasks, their context (regs and such). This reminds me of some of the small RTOS I have used.
I have something similar in that each Object-ID is mapped to its own handler Routine - not really this idea of having a Task as such it is more that the Super-Loop works out what needs to be executed.
However, my Shmup Engine is in its early stages so may change a lot
Cheers for the explanations, Trap and yes, it would be good if the Wikipedia page matched reality