It is currently Fri Sep 20, 2019 3:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Fri Dec 07, 2018 4:49 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21594
Location: NE Indiana, USA (NTSC)
PypeBros wrote:
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.

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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 5:53 am 
Offline

Joined: Sun Feb 04, 2018 8:00 am
Posts: 4
Banshaku wrote:
@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! :lol:) but is such topic is interesting, it can be discusses in another one.



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

that was atomic bulk mailing - great marketing stunt i suppose :lol:

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

Regards Top.


Top
 Profile  
 
PostPosted: Fri Dec 14, 2018 6:31 am 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 34
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.

Image vs. Image

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).

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Fri Dec 14, 2018 11:52 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
PypeBros wrote:
since the SNES produces an analog signal, dithering will work much better.

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:
Attachment:
120-colors-blarggNTSC.bmp
120-colors-blarggNTSC.bmp [ 678.05 KiB | Viewed 10389 times ]

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

Quote:
I had 190 unique colors on the background planes

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.)

Quote:
Some stuff will have to be converted to sprites, however, such as the 1-UP bonus

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

Quote:
or the ink waves (previously existing as either tiles or sprites depending on the situation).

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?


Top
 Profile  
 
PostPosted: Sat Dec 15, 2018 2:27 am 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 34
93143 wrote:
Quote:
I had 190 unique colors on the background planes

Your source image has garbage lines on the top and right side. Removing those lines results in just 105 colours total, including the sprites.


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.

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Sat Dec 15, 2018 5:31 am 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 34
Quote:
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".

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.

Attachment:
overlay3.png
overlay3.png [ 4.96 KiB | Viewed 10342 times ]


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.

Attachment:
overlay4.png
overlay4.png [ 3.3 KiB | Viewed 10342 times ]

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.

Attachment:
overlay2.png
overlay2.png [ 3.52 KiB | Viewed 10342 times ]

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)

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Sat Dec 15, 2018 6:52 am 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 34
Quote:
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.


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).

Attachment:
multicolors.png
multicolors.png [ 4.23 KiB | Viewed 10331 times ]


Sometimes, granted, the effect is just cosmetic, as the books are all solid or all walk-through anyway.
Attachment:
multicolors2.png
multicolors2.png [ 3.7 KiB | Viewed 10331 times ]

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.

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Sun Dec 16, 2018 7:53 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
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...

PypeBros wrote:
I ended up using it a lot to make the things more interesting by letting them overlap each other.

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

Quote:
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.

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.

Quote:
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)

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.

PypeBros wrote:
I really should have posted the full picture first

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.


Top
 Profile  
 
PostPosted: Tue Dec 18, 2018 2:37 pm 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 34
Quote:
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 ?

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Wed Dec 19, 2018 11:11 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
PypeBros wrote:
- the level editor

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...

Quote:
a technique where the map data can specify 2 tiles that must be merged into a single one.

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.

Quote:
I can have some bonus letters over the background books tiles, etc.

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.

Quote:
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 ?

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.


Top
 Profile  
 
PostPosted: Fri Dec 21, 2018 8:47 am 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 34
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.

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Tue Dec 25, 2018 5:18 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group