[NDS] Bilou School Rush

This is the game I've been working on the last 5 years, using my DS game tools.


It's a speed-oriented platformer featuring 4 main levels and one, long, secret level to close them all.

Have fun if you play it (DS linker or desmume 0.9.11+ recommended)
The engine is open source (LGPL), by the way.

Do you foresee any significant issues that would block a port to Game Boy Advance?

Well, I really haven't designed the pixel art to use 16-color palettes. It might still fit on a GBA, but when I checked for a SNES or a Genesis port, it was disappointing. I don't know how well the soundtrack would survive, either: my brother used quite much of the 16 tracks the NDS offers.

And the final thing is that I used C++ for the code base. I haven't heard much about succesful C++ coding on the GBA.

Don't have anything to play it on ATM, but it looks pretty slick.

Look nice!

What were the main bottlenecks? I haven't played the game, but I don't see anything that looks too challenging in that GIF.

But yeah, C++ probably isn't going to go well on the SNES (I'm not even sure the tools exist for anything beyond plain C, and they aren't good even for that). You'd have to convert performance-sensitive code to assembly. Which isn't incredibly hard on such a simple processor, but it might be more effort than you're willing to put in considering the game already works on a newer system three times as many people bought...

Then it might take someone with pixel art skills to color-reduce it to 4bpp so that the playfield background tiles can fit into 32K (1,024 4bpp tiles), the parallax background tiles into 16K (512 4bpp tiles), and the sprites into 32K (1,024 4bpp tiles). It shouldn't be that hard, as I discovered in 2002 that there's more than enough DMA bandwidth to stream sprite cels from ROM or from a decompression buffer in EWRAM to VRAM.


GBA has software mixing: more channels just mean more CPU time. Or there are tech demos that decompress streamed audio in real time as if it were a PlayStation game.


It really depends on which parts of the C++ language a particular code base uses. One often associates the GBA with the C language, but C in practice is also a subset of C++.* There are parts of C++ you can use without runtime cost, and there are parts you need to avoid if you're on anything smaller than a PC or smartphone <cough>iostream</cough>.

The big reason I asked about GBA is that there are countries where, due to technicalities of copyright law, GBA homebrew is legal but DS homebrew is not.


* Or more rigorously: The common subset of C and C++ purposely resembles C so closely that it's practical to write polyglot programs that mean the same thing in C and C++ by using C idioms as is.

Ah ? I didn't knew about that. Then yes, it would make perfect sense. So far the game is essentially using little 3D, almost none of the advanced background effects (unlike the tools) and only A+B+L+R for the input (Y and X mirroring A and B), so a port could be envisioned.


It should be manageable with 16x16 palettes for sprites and 16x16 palettes for backgrounds, indeed. The tiles count could work too, although only 512 tiles could mean some "advanced" backgrounds (in the secret level) would have to be dropped (that's ok). After checks, the thing that blocked me was that Mega-drive (which had my focus in the previous "demake" study) has only 4 palettes for both sprites and backgrounds and that was ... wel... not so appealing.


so that will all depend on how much CPU time I can save on the game logic. So far it is partly interpreted, partly running compiled code. On the GBA, there would be no stylus and no wifi to edit the game logic live, so it is perfectly ok to convert the interpreted part into compiled part as well.


A large part of the engine likely only use the 'no runtime cost' subset of C++. That is the code that runs once the level is loaded. The level and state machine scripts parsing, on the other hand, relies on vectors, lists and even key-to-value maps that C++ offers. But I've detailed the plans for that part above already.

I don't think I've been using iostream in this project. Mostly good old iprintf /siscanf.

So if it was the game-of-my-life, I'd definitely consider a GBA port right now. But it is just a subset of that game. Right now, porting School Rush to GBA is competing against doing a game in the Castle Zone and one in the Desert Zone, and then one in the Lost Temple Zone on the NDS... I cannot tell yet what will win.

Of course, if some seasoned GBA developer is willing to port the engine, I'd be more than happy to teamwork so that the game itself gets ported as well

May I suggest desmume emulator?

Looks pretty good! It's nice to see polished homebrew for the NDS. Feels like the heyday for that was mid 2000s/early2010s, so it's great to see people still making things for the handheld.

Mostly just wanted to say thanks for your efforts. I'm in the process of improving the NDS core of my emulator, and any sort of ROM I can use for testing is appreciated, especially interesting games. Despite the somewhat "meh" state of NDS emulation in GBE+, School Rush manages to run without crashing. Very impressive work you've done here, keep it up.

The interest may have waned but like retro console, it should have a surge someday when people rediscover them Now if I could find a way to test some code without a flashcart (it mostly died by now), I could try it again someday but I didn't touch since 2008 so I have no idea what changed in the nds scene since.

I remember using the ff4 tileset and make a quick map, just for fun and some snow falling (always liked to do that under dos) but this is as far as I went

we can hardly call it "a scene" anymore, although there have been some other people doing NDS homebrew games too over the year.

What I find nice about it is that (like any other console), it will never completely die: the hardware was fixed and so you can have emulators for it. Running MS-DOS games nowadays is still much more complicated than running NDS games, esp. if the developer had funny hardware, or was using CD-ROM, or hadn't foreseen MHz speed increase, etc. I don't even want to think about emulating early Win95 games like Lion King (although I might discover it isn't as hard as I think).



Nice ^_^. One thing I had in mind to ease the porting towards other platforms was to merge the C++ logic of the code with an NDS emulator. We'd still have emulated sound & graphics, but the CPU wouldn't need emulation because there would be native code instead. Is that something GBE+ would make possible / easier than hacking desmume source code ?

I think the wifi demo functionality can be used, but only for small apps since they load to RAM.

@calima

Ha yes, I think I even asked a question about it ^^;;; For now what I do would be just pure testing so I guess that could be more than enough. I should get another flash cart someday but I would prefer one for either famicom/gameboy first since this is the one that I'm the most active at the moment (gameboy, maybe soon, I'm curious).

You're just a bit too late, krikzz's black friday sale was 1.5 weeks ago.

Realistically speaking, GBE+ is in no shape to be used regularly as a replacement for Desmume. I can get School Rush to run, but there are a bunch of issues with GBE+ (not 60FPS, no sound, slow to load levels due to bad timings, etc). It "works" meaning it doesn't cause the host PC to explode

Repackaging Desmume or MelonDS would be much more feasible as GBE+ is quite a bit behind both. So far, the only professional software that actually boots and runs in GBE+ are some demos. I've had no success just yet with commercial carts (although with any luck, maybe Super Princess Peach will run soon).

Anyway, I don't want to dwell on my project in a thread about your project. I have an NDS flashcart, so when I get the chance, I want to play this on my DS Lite. Maybe I'll get the chance this weekend. It's great that you have other example games on SoureForge too!

I think what he's done is he's attempted to come up with a notional resource allocation plan for the limited VRAM, without knowing about the secret level. I'm pretty sure there are no BG layers that are restricted to 512 tiles in hardware.

A single BG on the GBA can use a pool of 1024 tiles (16-bit tilemap with x/y flip bits and 4-bit subpalette), unless it's an affine layer in which case it can only use 256 tiles (8-bit tilemap, no flipping or subpalettes). Basically the same as the SNES, except the non-affine BGs on SNES only use 3 subpalette bits; the spare bit is used for tile priority.


The SNES has 16 palettes in total (when using 4bpp BG layers): 8 for backgrounds, and 8 more for sprites. Obviously you can freely rewrite the palettes between frames, and even between scanlines (up to 8 colour changes per line without special tricks), though it doesn't look like you'd need the latter.

The SNES also allows 1024 tiles for each BG layer, although sprites can only use 16 KB (512 tiles) at any one time. These tile pools can overlap. Their starting addresses in VRAM can be freely changed between scanlines (doing this with sprite graphics requires an undocumented trick, but it seems to work fine), but there's only 64 KB of VRAM total, so this may be of limited utility. However, you can of course stream tiles during VBlank. With the standard screen height (no letterboxing) in NTSC, you can stream about 130-190 4bpp tiles per frame depending on what else has to get done during VBlank. PAL is substantially easier as the frame is longer; even with a 239-line active area you can stream perhaps 320-370 4bpp tiles per frame on a PAL SNES.

You also get two multipurpose window masks, which can be used to draw simple shapes onscreen.

You only get 34 8-pixel slivers worth of sprite overdraw per scanline, but you do get three BG layers in the most common BG mode (Mode 1), with one of the layers being 2bpp (seems ideal for the ink).

One notable difference between the SNES and the DS is that the pixels aren't square. The standard 256x224 NTSC SNES screen has about the same aspect ratio as the 256x192 screen on the DS, and a PAL SNES can't render enough scanlines to make the display 4:3 without pillarboxing. You could trim the screen on the SNES to get 256x192, with the added bonus that you'd be able to stream about twice as much graphics data during VBlank on NTSC (~300-360 tiles; even more for PAL of course), but the image would look horizontally stretched unless it was being played on an emulator with square pixels. ...more precisely, if you didn't want the graphics to look stretched, you'd have to rescale them, at which point you'd probably want to use a different screen size anyway...

...

Again, though, you or whoever was porting it would have to be willing to rewrite at least part of the game in assembly. I'm unaware of any C++ solution on the 65C816, and C is not performant on the SNES, partly because the compiler situation is not good and partly because the CPU simply isn't well suited to C. The Mega Drive has none of these problems.

unsure how krikzz could have helped me to that regards.

I think his comment was related to my interest to get someday a flashcart, which seems was on sale for black friday. Since I'm in Japan, I'm not following those kind of sales because it's US specific (well they are starting to do black friday sales in Japan as a new marketing trick these days but it doesn't make much sense ^^;;;).

But then Japan is next door to China, where they have a huge Veteran's Day sale roughly two weeks before Black Friday.

@tepples

Japan don't follow Chinese holidays, that is for sure. As for the subject at end, Black Friday in Japan is something fairly new, maybe a few years ago, and is mostly a marketing stunt for creating sales. This is similar to Valentine day/white day in Japan, where they added an extra day (white day) on march 14, where you gave back something, thus extra sales. Most "imported" holidays/event is Japan is for commercial purpose only.

Now we are completely off-topic (nesdev! ) but is such topic is interesting, it can be discusses in another one.

Canada pretty much fully "celebrates" Black Friday and Cyber Monday and all the rest of it, at the same time the USA does. Even though our Thanksgiving is in early October...

Oh my god, I don't know for Japan but here in Switzerland they never stop to force importing shitty american commerical "days". Back when I was 10 (that is, 20 years ago) they suddenly introduced Hallowen, a feast nobody had never heard about before that point and that in only 2 years became incredibly popular - and they manage to sell all kind of shit for this occasion, with medias talking all about it suddently, as if it had always been there. Now 10 years ago they introduced Valentine's day, with always the same purpose (selling stuff); and last year Black Friday was introduced for the first time - once again nobody had no idea this existed 2 years ago, but this year all media, and stuff was only talking about "black friday", as if it had always existed since decades. And guess what ? They just sell shit that would never sell, for a reduced price, and people belives they make a good deal - when in fact the real good deal would have been to never produce the said shit in the 1st place. Not to even mention they didn't translate the expression "black friday", just leave it in English to show how cool and american this day is.

Not to mention old feast days, such as Christmas or Easter, are turned into commercial feasts and have nothing to do with the christian celebrations they still were only 20 years ago. Pentcost day is now turned into a long week-end where people have to buy cheap easyjet tickets and spend their money to visit the world.

Holy shit we're really in a decadent society. God knowns what's coming next. I bet in a few years we'll get some more shit from america such as thanksgiving or whatnot - because those people can't stand that other countries don't do everything they do. For a while I though the election of Donald Trump would made people stop to want to imit America in all circumstances, and while for some people this worked, there's so much innertia that it doesn't change mentalities as quick as Black Friday was introduced.

Pretty much the same story here (a bit more in the North of Europe). It is completely ridiculous and somehow pushed by the large online shops. Someone managed to convince a few big players in the non-electronic business that they **need** to offer deals on that day too, but of course noone has a day off on that day because there is no reason thanksgiving would happen out of the US. So they extend it to "black week-end", which is even more ridiculous since this is the way we used to call worst possible time of summer when it comes to traffic jams. I hope I'm not the only one to have snobbed that and they will realize they wasted their money, but I doubt that will be the case. Selling Sales to most people is about as is as to sell sweets to kids. °_°

That's more or less what I was afraid of. Well, I have significant knowledge of assembly, but mostly for 80x86 CPUs and a little bit for the 6502 (which might get handy for the 65C816). The idea would then to convert my RISC-like animation instructions (currently interpreted by the ARM CPU on the NDS) directly into machine code, and same for the behaviour transitions where the list of iGobController would essentially turn into a set of CALL instructions.

An interesting problem, but I don't know if I'll end up with a running game or just excessively techy tools if I follow that path.

I mean, one could try it in C and see how it goes. Given how common slowdown was even among games programmed in assembly, and given how suboptimal C code tends to be on 65xx processors, I wouldn't expect a flawless result. But I could be wrong...

A working C version could be profiled, and the slow parts rewritten in assembly. To a 6502 programmer, 65C816 is a big improvement; the only real disadvantage is that you have to keep track of the sizes of the accumulator and the index registers (cc65 avoids this issue by doing everything in 8-bit mode).


That seems to be a risk with any kind of SNES development. It's friendlier than NES programming, but it's more complicated because you can do so much more with the console, and it's not nearly as friendly as a modern C++ framework. It's not something you can just turn to and dash off a quick side project in a few weeks; you have to be serious about getting something done.


Perhaps. This one's a bit unusual, because with Mega Drive or arcade ports, they're already 224-line games and ideally would only need horizontal rescaling, but this is a 256-wide game that only needs to be scaled vertically. This means that it may be easier to rejigger the level maps, because horizontal widths and distances don't change.

Or you could just leave it the way it is:

Original:

NTSC:

PAL:

(Please excuse the colour/gamma; the processing was kinda ad hoc...)

...

Regarding music, the SNES (as you may have noted) is limited to 8 channels including sound effects. They're all sample channels (or optionally noise), so you can use chord samples to boost the apparent polyphony. But there's only 64 KB of RAM for BRR samples, audio engine code, and the echo buffer, so if you're using a lot of sophisticated instruments you're going to bump your head. This memory limit shaped the sound of the SNES at least as much as did the capabilities of the DSP, and it didn't help that most developers were in too much of a hurry to spend much effort exploring the limits of optimization.

Real-time sample streaming is possible, as proved by Tales of Phantasia and Star Ocean, and there are a couple of homebrew audio engines that support it. But for various reasons they're more bandwidth-limited than I personally believe they could be (though I'm too busy to prove it), and last I checked you could only stream muffled mono. Good enough for sample replacement during playback and for some types of sound effects, but without more development you aren't going to be streaming 32 kHz stereo, not that a SNES cartridge could hold much music at that bitrate anyway...

The MSU1 is a possible way around this (up to 4 GB of Red Book audio with loops), but it loses authenticity somewhat as it is not period hardware, and not every emulator supports it. The Nintendo Play Station could potentially be used for CD audio, but it was never released and there's only one known extant hardware unit, with the result that it is not especially well understood or widely emulated. The Voicer-Kun is another period-accurate possibility, but in addition to the extra hardware (which was only released in Japan), it requires the use of a CD player with infrared remote control functionality, which may be overkill when you could just put up with somewhat cut-down music instead...

Very interesting. Thank you for taking the time to do that. I'd say the vertical squashing is tolerable, except maybe for the main character. Hopefully, it has 2 to 3 transparent lines at the bottom of its 16x16 frame so far, which I could use to slightly expand it and compensate the squash.


The soundtrack has been composed by my brother, and hopefully, he now also has experience with C64 (wolfling, powerglove) and NES (wolfling) composing. He's been doing lots of covers to chiptune, so I feel like he could be able to write a convincing score within the SNES limitations, possibly much quicker than the time it would take me to adapt the code to run over e.g. Alekmaul's library.

Interestingly, the extra 32 lines of the SNES could also be used to display a suited HUD, since I'm losing the bottom screen where we had the HUD so far.

Do you know whether something special would be needed to run a GBA homebrew through a "Supercard SD" linker ? I remember I had to patch commercial rom back then, but I'm afraid I lost the .exe that was doing that together with my Win98SE back in 2007.

By the way, I tried some preliminary fitting on 16-color palettes. With 5 or 6 of them, I think I cover most characters. They are typically 8 to 12 colors so I can even split the variants of e.g. feet among other palettes.

As I explained in an answer on Retrocomputing Stack Exchange, SuperCard's GBA patcher does two things: 1. convert save type from EEPROM or flash to SRAM, and 2. change the memory controller mode (WAITCNT) from fast ROM to slow ROM (which is all the SuperCard's RAM supports). Essentially all commercial games use fast ROM, but homebrew need not. If you use no save or SRAM save, and you don't switch to fast ROM mode, you don't need the patcher.

You have no idea how much spam I received in my mail befor black friday from China

that was atomic bulk mailing - great marketing stunt i suppose

Somewhere around 500 letters in half a day come in my mail

Regards Top.

Just realised ... since the SNES produces an analog signal, dithering will work much better. I had 190 unique colors on the background planes, but I can shrunk them down to 120 with some dithering, even if automatic.

vs.

Some stuff will have to be converted to sprites, however, such as the 1-UP bonus or the ink waves (previously existing as either tiles or sprites depending on the situation).

Dithering doesn't tend to look that great on SNES. The analog signal isn't bad enough to smooth out the dots, but at least on NTSC it can cause them to shimmer when the screen scrolls. Also, a lot of emulator users go for "HQ" filters or just leave the pixels blocky.

I've run your colour-reduced image through blargg's NTSC filter with medium settings and no other processing, to show you roughly how it would look:

Kinda looks like the pencils have the chicken pox...


Your source image has garbage lines on the top and right side. Removing those lines results in just 105 colours total, including the sprites. (Also, I should note that the colours are incorrectly converted from 15-bit - they've been multiplied by 8 instead of properly expanded to the full range of 0-255. This gets you a slightly duller picture, with a "white" having RGB values of 248, which is slightly gray.)

You're probably going to have to manually palettize the BG graphics anyway; the 256-colour modes use too much VRAM. Do you really need more than eight 15-colour BG palettes at the same time, taking sharing into account? Could you just keep track of where in the level you need which palettes and switch them out on the fly during VBlank?

...

Let's see... The foreground wooden blocks are 10 colours, so you could fit 5 more in there. That covers the ink layer, with probably two colours left over if you're using BG3 for it. The pencil eraser with its metal clamp also uses 10, and the letters use 5, which completes another palette. The book appears to use exactly 15 colours. The far background seems to use just 7 colours all told; perhaps something useful could be done with the other 8. The pencil shafts appear to mostly use 6 colours each, with 8 more for the point; this may be excessive considering there are at least five shaft colours in this screenshot. Perhaps the pencils could be redrawn slightly to keep the shaft colours off the point tiles, and either reduce the number of shaft colours or make sure no more than three point colours appear on shaft tiles. This would allow two pencil shafts to be packed into one palette (doubling the number of tiles required for the pencil shafts, but that number isn't large), and for the point to use the spare 8 colours in the far background palette. This brings us up to seven BG palettes containing no more than 86 unique colours, or 84 if you don't count the ink.

So the screenshot you've posted would work on the SNES with minor modifications to the pencils (which might make them look more like the originals by compensating for the aspect ratio shift), with an ink layer in reserve and a whole spare BG palette available, all without needing fancy tricks. You could even add another pencil colour and still have that spare palette. I doubt the above is the smartest way to distribute the colours, but at least they all fit.

You could do it without any modifications at all by using sprites for the pencil points, but that would eat half a sprite palette, and you might want to save those...

...

It might actually be smart to use HDMA to overwrite one of the BG palettes in between the playfield and the HUD, so you can use all 8 BG palettes for the playfield.

If all else fails, you could even start changing colours partway down the playfield, as long as you've got vertically-separated elements such that the upper one won't glitch when you start overwriting its palette for the lower one. In this case, note that the shafts of the blue and yellow pencils are separated by 92 scanlines; once the blue pencil shaft has been drawn, it would be perfectly safe to overwrite its palette with the yellow one's palette during HBlank (and reset it again after the yellow one has been drawn but before the blue one starts being drawn next frame) so as to get away with only allocating four pencil shaft palettes instead of five. But that's an emergency measure and hopefully won't be necessary...

That said, the use of HDMA on this image would allow it to be reproduced on SNES without any modifications, and without having to use sprites for any element that wasn't removed in the dithered version. (It would, however, need to use all 8 BG palettes to avoid attribute clash between the pencil shafts and points; this is what redrawing the pencils fixes.)


That's basically a picture of the main character, right? Sounds eminently reasonable, as then they can share a palette.


If you're using Mode 1, you have a third BG plane available that uses 2bpp graphics (3 colours plus transparent). I imagine this would be well suited to the ink layer. You'd have to colour-reduce it slightly, but it shouldn't be a big deal; I had to look pretty closely to find that out.

Sprites are a bad idea for this, if I'm correct about what you mean by "ink waves". The SNES can only render 34 8-pixel sprite slivers per scanline. The ink waves span the whole screen from left to right, and since you're scrolling them horizontally you need at least 33 tiles per row. This leaves just one additional 8x8 sprite tile that can appear on those scanlines before you start seeing dropout. And since the SNES renders the OBJ line buffer from back to front, dropout looks really bad because the stuff that's supposed to be on top starts to disappear...

You don't need to reserve BG3 for the HUD. The SNES allows you to freely change BG scroll values and even map/data locations in between scanlines. Any playfield BG layer could be repurposed in this fashion, so you can use all three for the gameplay screen.

Are there parts of the game where you need more than two scrolling tiled layers besides the ink?

Impressive reply! thanks. I haven't read it all yet, but you need to know that the comparison picture with sprite wasn't my source image. here it is. (and of course, it had the window border properly cropped). I picked this particular snapshot because it allows to see the compromises resulting from dithering quite clearly.

And yeah, I noticed the chicken spot on the pencils. This could be easily fixed. What I like is that the color reduction did no flatten out the structures (including book and pencils) as it previously did.

Indeed, just one 8x8 sprite before flickering won't be sexy. Unfortunately, I already use 3 planes in the DS version: one with the owl background and two with the playfield. The initial motivation for that was to have Bilou either above or below some structures (which I know the SNES could do without one additional layer) but I ended up using it a lot to make the things more interesting by letting them overlap each other.



The number one use is to have some "inner" structures. Such structures are inherently rectangular, so I suppose I could at worst have a owl/wall BG switch with a hsync / HDMA / window effect.


There are places where I use that to make things visually more interesting, but without affecting the gameplay. I could put the 'hand' back as a downwards object at some places or have the fingertips implemented as sprites at other places.


Then there are places where overlap allows to make the level out of meaningful and fairly large structures (books, binders) instead of arbitrary floating platforms. I have almost no perfectly square structures, but I guess I could simplify the problems by using more wooden blocks here and there (or a new very rectangular object)

The thing is (I really should have posted the full picture first) I use the colors of the pencil shafts for vertical books and binders too. One more thing to consider is that the color used for these hints the player on whether the objects are solid (e.g. the green book, and other saturated colors) or walked through (the purple book and the brown pencil and other dark/desaturated colors).



Sometimes, granted, the effect is just cosmetic, as the books are all solid or all walk-through anyway.

I think using different colors then helps making the area unique and ease memorizing the level layout.

Chances are, indeed, that I rarely need all the colors at once, and when I do, that one or two palettes might be sacrificed by e.g. keeping locally only one color for the 'background' books and one for the 'foreground' books.

I just realized that the pencil's back end has a single line of metal pixels in a couple of the shaft tiles. This throws off my previous calculation, and is the sort of thing one might have to consider changing if one were to run out of palette space...


Sounds like a job for sprites, if most of the examples are as sparse as those you've shown...


Horizontal raster splits, where the render parameters are changed on a particular scanline, are trivial on SNES. But it's not as easy to do a clean vertical raster split. And unfortunately you can't use windowing to switch BG settings; windowing is only useful to mask off a layer or effect that would otherwise already be rendering.

My unnamed shmup port has a vertical split between the playfield and the sidebar, but it's done with an H-IRQ that eats a big chunk of my frame time (if I weren't using a Super FX it would probably be prohibitive), and I needed sprites to mask the split because the timing simply isn't precise enough to hit a specific pixel on each line. (Well, that and I'm actually changing the BG mode as well, so there's a few slivers worth of garbage before it settles out in the new mode, and sprites mostly mask the garbage.)

If you're just changing scroll, an H-IRQ with a sprite mask to hide the imperfect split could work, but it would take a lot of CPU time because the IRQ has to run every line; you only get maybe 40-60 instructions per line in total. Instead, I'd look at either judicious use of sprites or just reserving a couple of slots in every palette that has to overlap the near background (it's only two colours, right?), depending on palette load and on whether you need sub-tile priority in a particular case.


Again, if these are relatively localized conflicts, you could (as you say) use sprites in cases where it's unfeasible to combine both objects into one palette. One potential issue is that you'd have to waste part or all of a sprite palette duplicating the BG palette, and if a lot of enemies and objects are on screen you might run out of palettes.


Don't worry about it; I'm not trying to dictate to you how to handle your game. I'm keenly aware that I haven't seen the whole thing, and it's your game anyway. I'm just trying to suggest possible approaches to graphics optimization within the limits of the SNES, without treating the limits as even more restrictive than they are.

And I thank you for that. It's much more stimulating than just digging through some SNES docs with no helping hand and not a clue on whether things could actually be achieved. I see two things that I'd need to work on before I can port the game to the SNES

- the level editor should be allowed to render some sprites with 1:1 ratio precisely where they would appear (currently we just have a hint on the hotspot location and a thumbnail of the sprite)
- the engine should be able to swap tiles from ROM to VRAM, and for this very game, preferably with a technique where the map data can specify 2 tiles that must be merged into a single one. That way I can have e.g. the pencil tip over nothing, and at other times the same pencil tip over some of the 4 "background wood". I can have some bonus letters over the background books tiles, etc.

Out of curiosity, do you know any open-source engine that would already feature something alike, or do people prefer to stick to SMW-like engines where tilesets are written to VRAM only when the level is loaded ?

The what now? Is this a development tool you're talking about or part of the game?

If the player can edit levels, he's going to run into palette conflicts and sprite overload much more easily than on the DS. The game might need some way of preventing the user from specifying a non-realizable level...


Honestly, I'd prebake that. Just use a different metatile for the pencil point if it's supposed to be in front of a near wall.

But I have no actual experience with platformer engines, and very little with map decoders in general. Maybe this makes sense in the context of a compressed level map, perhaps one where graphics and collision data are combined in one scheme. Particularly if there's an in-game level editor... You'd still want to store the combined tiles in ROM, though; software rendering is not something you should be doing on SNES if you don't have to.


That really does sound like a job for sprites.

Although if the colour of book in question has no visible pages anywhere (or just in the same scanline range as the bonus letters if you want to do palette HDMA), there should be enough free colours, and you could do much longer horizontal runs without endangering the OBJ fillrate limit. On the other hand, you might run into conflicts if there were pencils that needed to use the same palette, depending on whether and how you rework the graphics. Again, HDMA could save you, but only if the conflicting palettes don't share scanlines.


One of the problems with SNES development is that the tools are a bit scattered and not very comprehensive. Generally people write their own engines and a good bit of the toolset. Part of this is also because with a system this old, it's hard to write a flexible, generic engine that's also adequately fast.

People have done crazy things with the Super Mario World engine, and there are some impressive tools for SMW hacking. But that's almost a separate universe compared with the largely from-scratch development we do on this board, and I don't know very much about it. Also, the SMW engine was cobbled together in parallel with the hardware development and is not particularly clean or efficient.

I'm probably forgetting something, but the only actual publicly-available engine project I can think of off the top of my head is Superfeather. It's still a work in progress, but it's something. If anyone reading this knows of any potentially useful examples, feel free to mention them.

The level editor is a NDS tool, but it isn't part of the game itself. I would love to have more people using it to make their own games on NDS, I start making plans to let it be usable for GBA and possibly SNES titles, but it isn't intended to be shipped with either version of the game.

And indeed, I could pre-bake combined tiles as part of the level-editor-for-XXX exporter. I'd prefer to avoid having the combined tiled as part of the tileset the pixel artist edits. I've done that in the past and it was really a pain, to the point where I stopped developing on that game altogether.

I'll give superfeather a look. Thanks for the hint.

It occurs to me that if BG layer elements follow a 16x16 palette grid, you could use 16x16 tiles and save a good amount of space on tilemaps.

Also, if you've got a tilemap that's mostly unused (ink BG3 with HBlank enable/disable of BGs?), you could fill the unused portion with more tile data. Of course, this won't usually net you more than a few KB at best, so it's only useful if you're on the edge.

I wish somebody else would say something. I'm not exactly the foremost expert in SNES development...

...

Also, I'll completely understand if you decide not to do this. I just want you to make an informed decision.