Historically, a "brique" used to be a million of anciens Francs (old Francs), then converted to 10 000 nouveaux Francs (new Francs) in 1960.
Since the switch to euro, I think the most commonly accepted value of one "brique" is (unofficially) 10 000 €, but the uncertainty makes it basically useless.
After I made the emulator I trawled GitHub to try to find games it could play within the 32K limit. I found yours - thank you :-) - and the ./try.sh script has an option to download it from GitHub for the user to test.
I played a bit with original gameboy too. I was very surprised when, iirc, the cpu is not even fast enough to clear the screen in one vertical blank, or even in one frame! It takes like three to fully clear the map.
Yeah, you really need to structure your code around working with the tilemap system.
I did a small racing prototype with both vertical and horizontal scrolling and segmented my updates to 4x4 blocks of tiles per-frame (160x144 resolution so 20x18 of 32x32 tiles is visible at any point in time, so stippled updating 4x4 blocks outside of view is within the budget together with updating some of the tiles each frame)
You need to do mid-frame tile updates just to show a full bitmap frame. There’s 360 8x8 tiles on the screen, but the tile indices are 8 bit (you can only reference 256 tiles). You can store only 384 tiles in VRAM - a bit more than a full screen. So the mid-screen update is to go from one tile dictionary to the other, so you can access 360 tiles in total.
You can update 1 tile per scan line (during hblank), so 154 tiles per frame (including 10 vblank scanlines). So you need 2.5 frames to replace all tiles.
If you are really smart about updates, you can “race the beam”, basically start updating tiles just as the frame starts rendering, just behind the active scan line. Then you can update maybe 280 tiles before the active scan line of the next frame catches up with you.
Great resource! But a lot of it is very old. I recently discovered this open source ds cart[1] and an alternative SDK[2] to devkitPro. Both were used in the development of a demo[3] released at Revision this year.
Even the version linked to is out of date. The homepage links to a version of this guide[0] updated as recently as 2024. Still likely not the best place to get started.
Yea, the link really should be switched to this. Has a much more modern feel, hell as I was reading the OP the reason why I opened the comments was to see if someone commented on how dated the UI was.
I don't have an issue with the style personally. I actually like being able to navigate the whole page without clicking through pages. Looks like the content is the same too? Although that's just a glance comparing random snippets.
Because the article is about hardware formats, not storage formats. GPU hardware formats are left compressed in GPU memory, the GPU decodes it on the fly. Basis universal must be decoded to a GPU hardware format (or to plain RGBA) before it can be used by the GPU.
Well, it’s texture RAM, the only one that RDP can access. It’s closest thing to « video memory ». Although, you’re right as the framebuffer lives in main ram. But that just means the system is sharing like in modern hardware, so I wouldn’t call the main RAM VRAM in any way.
reply