What's new

GB Enhanced

OP
S

Shonumi

EmuTalk Member
I thought about a key press (like keys 0-9) to act like slots. That would definitely work, I'm just not sure it's a perfect solution. It'd work great if you switch levels or areas that use a solid color to represent different things (a forest, or a mountain, like Kirby's Dreamland). But what if you wanted the sky and the ground to be separate graphics? In the picture you posted, GBE would take the first row 8x8 tiles underneath the HUD and make them the same tiles as the ground. I think I have a decent solution, but I haven't exactly tested it out yet.
 

LyonHrt

Dcemu.co.uk guy
I thought about a key press (like keys 0-9) to act like slots. That would definitely work, I'm just not sure it's a perfect solution. It'd work great if you switch levels or areas that use a solid color to represent different things (a forest, or a mountain, like Kirby's Dreamland). But what if you wanted the sky and the ground to be separate graphics? In the picture you posted, GBE would take the first row 8x8 tiles underneath the HUD and make them the same tiles as the ground. I think I have a decent solution, but I haven't exactly tested it out yet.

Yeah that is quite restricting, in that pic you see the grey blocks for the ground is also the same as under the score. I did read a bit with what the hdnes author and ideas on how he would tackle the problem, with the use of scripts. Whether the same ideas could apply here i don't know.

the topic discussing that is here.
 

chiburunga

New member
I thought about a key press (like keys 0-9) to act like slots. That would definitely work, I'm just not sure it's a perfect solution. It'd work great if you switch levels or areas that use a solid color to represent different things (a forest, or a mountain, like Kirby's Dreamland). But what if you wanted the sky and the ground to be separate graphics? In the picture you posted, GBE would take the first row 8x8 tiles underneath the HUD and make them the same tiles as the ground. I think I have a decent solution, but I haven't exactly tested it out yet.

In that specific case, that there are tiles aways on floor and always on the sky its possible to program the emulator to show diferent tiles according to their coordinates at emulator screen?

Example:

original tile with solid color is xxx.png
if originaltile is in upper half of the screen show substitutetile x
else if originaltile is in botton half of the screen show substitutetile y

Maybe associate with the percentage of y axis so it can adapt to any resolution of the screen and we can have different options of solid tiles for different parts of the screen.
 
OP
S

Shonumi

EmuTalk Member
[MENTION=88462]chiburunga[/MENTION] - That would work as well, but only some of the time. Imagine you have the ground being a solid color and the sky is that same color. Say you did replace them both based on their Y coordinates so that the sky is blue, and the ground is brown. Now imagine the player falls into a pit, and the screen scrolls down too. Eventually the "ground" tiles scroll up to the top of the screen (imagine the walls of the pit take up the full vertical length of the screen). Some of the topmost "ground" tiles would accidentally be replaced with "sky" tiles, even though in the game you're in a pit, away from the sky.

The best solution I've come up with yet works like this:

Dzn6HcM.png


The emulator chooses one tile to act as a sort of "anchor". It looks at the "anchor", then if any tiles above, below, left, or right of it match a solid color (gray in this example), it replaces them accordingly. You'd be able to specify which tiles above it are for the ground and which tiles below it are for the sky. Left and right seem less useful than up and down, but it's no trouble to implement them all. When a new anchor comes on-screen, then it can switch to something else, so making different graphics for different levels is possible. The tricky thing is making this easy for the user. I don't want them to spend more than a few seconds on it, and no head scratching, screaming at the computer, or pounding on the keyboard ;)
 
Last edited:

chiburunga

New member
[MENTION=88462]chiburunga[/MENTION] - That would work as well, but only some of the time. Imagine you have the ground being a solid color and the sky is that same color. Say you did replace them both based on their Y coordinates so that the sky is blue, and the ground is brown. Now imagine the player falls into a pit, and the screen scrolls down too. Eventually the "ground" tiles scroll up to the top of the screen (imagine the walls of the pit take up the full vertical length of the screen). Some of the topmost "ground" tiles would accidentally be replaced with "sky" tiles, even though in the game you're in a pit, away from the sky.

The best solution I've come up with yet works like this:

Dzn6HcM.png


The emulator chooses one tile to act as a sort of "anchor". It looks at the "anchor", then if any tiles above, below, left, or right of it match a solid color (gray in this example), it replaces them accordingly. You'd be able to specify which tiles above it are for the ground and which tiles below it are for the sky. Left and right seem less useful than up and down, but it's no trouble to implement them all. When a new anchor comes on-screen, then it can switch to something else, so making different graphics for different levels is possible. The tricky thing is making this easy for the user. I don't want them to spend more than a few seconds on it, and no head scratching, screaming at the computer, or pounding on the keyboard ;)
Thanks shonumi! I Think that a easy way to select a tile as anchor is to put a flag in the name file... example:

actualtilename.png

To make this tile the anchor just rename to actualtilename_anchor0001.png and the solid tiles to actualfilename_above0001.png or actualfilename_bellow0001.png

Could also use the HUD tiles to make anchors... for example if tile corresponding to 1 - 1 (in world 1 -1 in mario hud) use tile x to substitute solid tile y
 
Last edited:

hi-ban

New member
The fact is that, although both tiles are identical, they are not the same tile.

If you look at the tilemap from that part of the game, you find the following tiles loaded in memory (see attached pic).

The ones highlighted in red (tile 232 and tile 339 in this case) are the ones used for the ground (232) and the sky (339).

So if you find a way to identify where in the tilemap is that particular tile, then depending on that, you can replace it with different tiles.
 

Attachments

  • tileset_marioland.png
    tileset_marioland.png
    13.2 KB · Views: 447
OP
S

Shonumi

EmuTalk Member
The thing is, while this works for SML (using tile numbers to differentiate tiles with the same pixel data) it's not a global solution. Other games will use the exact same tile with the exact same pixel data to draw different parts of the BG. The problem isn't getting it to work with one game in one instance; it's about getting to work for every game under every reasonable circumstance. The solution you've brought up has been mentioned before (just look at the tilemap entry numbers to add to the hash) but it will still mess up other games.

What's worse about relying on tile numbers (for both OAM and BG VRAM data) is that there is always the possibility for things to get reshuffled whenever the screen scrolls. It's not a problem in SML (you can clearly see all of the data for World 1-1 is loaded) but other games constantly swap out stuff and rearrange the tiles.
 
Last edited:

hi-ban

New member
Yes, i'm not telling to replace the detection method. But for those special cases where there are identical (but separate) tiles, you could do:
IF (Your actual tile detection method) AND (tile position is 339) THEN use tile "sky". For all other cases, then it would use tile "ground".
It could be done as additional conditions, so the user can "add" this condition in the cases where he needs it.
 

chiburunga

New member
Maybe it is impossible to have a universal type of tile anchor... maybe the way is to have multple anchor logics, so the remaker could select the most apropriate for each game.
 
OP
S

Shonumi

EmuTalk Member
[MENTION=112914]hi-ban[/MENTION] - See, but there's no guarantee at all that tile numbers will be consistent while playing the game. Even if using tile numbers were an extra condition, imagine you have a GB game that shuffles VRAM around when it scrolls to load new sections of a level. Looking for tile position 339 might be suitable for the first few screens, but as soon as the player starts moving, the game logic shifts everything around. The tile at tile position 339 is now somewhere else (225, 181, 5, anything really). Not every game is like that (SML is not one), but in many games tile numbers are quite arbitrary. That's one of the reasons I've been against looking at tile numbers/positions from the start; they can change at any moment, potentially. I prefer anchor tiles because they're independent of everything else except the actual 8x8 pixel data.

[MENTION=88462]chiburunga[/MENTION] - Yes, just using one anchor tile (for the whole game, or even a single level) is actually impractical. The system would allow for multiple anchor tiles. Naturally, if two have regions that overlap, the one processed last will take priority. As long as users know how to use anchor tiles, they should be able to avoid conflicts where one tile "fights" to be shown over the other.
 

LyonHrt

Dcemu.co.uk guy
I see that you now have implemented your sprite dumping and bg dumping to gbe+, are you going to include gba support, and any of the improvements discussed here?
 
OP
S

Shonumi

EmuTalk Member
No, GBA dumping is going to be a lot more complicated than GB or GBC dumping. The trick is coming up with a reasonably fast way to hash sprites and BG graphics without killing performance (although GBE+'s GBA performance is abysmal as it is...) I'm going to look at how other emulators hash things. For the GB/GBC, it's simple enough since you're only messing around with an 8x16 sprite at most with 4 colors. The GBA, however, could have all kinds of sprites (with 255 visible colors).

GBA custom graphics is something I want to work on later. For now, I'm just trying to make GBE+ on par with the old project (well, better once the GUI is finished).
 

LyonHrt

Dcemu.co.uk guy
Sounds good so far, and yeah i didn't think gba would be easy in that department, a lot more going on, yeah can't wait to try out good luck!
 

LyonHrt

Dcemu.co.uk guy
Hows the progress doing, have you done a windows build yet, i'll have to get around to compiling it to try it out :drool:
 
OP
S

Shonumi

EmuTalk Member
Sorry, no Windows build yet. :whistling

I get side-tracked based on whatever takes my interest at the time. It's been all over the place, from Custom Graphics (aka tile replacement), GBA compatibility, GBC compatibility, LOTS of GUI work as well, and odds and ends (NDS support in in it's baby steps too, in a separate branch). Recently, I added support for the MBC7, which basically means Kirby's Tilt 'n' Tumble works with keyboards and joysticks. I'm turning my focus back to Custom Graphics (abbreviated as CGFX) because I want to get everything in shape for a 1.0 build. I'm aiming for April 1st of this year (no, it's not a joke! I've done April 1st releases before lol), so I'm trying to clean up CGFX.

Right now, I have it so you can browse all the tiles from a menu and dump them by clicking. Just point at the screen and it dumps the graphics. Whereas the original GB Enhanced project only supported DMG games for CGFX, GB Enhanced+ supports GBC games as well. Previously in the old project, it was experimental, but now it's fully functional (well, 98%, still a minor sticking point I have to take care of).

I mentioned stuff about "anchor" tiles previously to deal with multiple instances of the same tile (e.g. ground vs. sky), but I abandoned that. It's overly complicated to get it to work, so I took the easy route and just used VRAM addresses similar to what hi-ban said. The thing is, the problems I pointed out still exist when relying on the VRAM address as an identifier, so it's completely optional for users when they start making CGFX of their own. If the game causes issues, they can tell the emulator not to use VRAM addresses for that specific graphic. For most games though, things should work as intended.

So yeah, the next few months are going to be a lot of polish + shine to make the emulator ready for April :D
 

LyonHrt

Dcemu.co.uk guy
nice, looking forward to using it, i have kept up with your very active github (now to think what game to have custom graphics for :blink: )
 
OP
S

Shonumi

EmuTalk Member
I know EmuTalk was where GBE first came onto the emu scene, so I feel bad about not updating this thread at the beginning of the month. Needless to say, I'm trying to get the 1.0 release done (preferably by the end of the month). A lot has changed since 2014. There's a GUI, save states, and the custom graphics are easier than ever to dump and load into a game. Currently, the Release Candidate 2 is available here -> https://goo.gl/SWPxrg

If you guys get the chance, check it out and let me know what you think. Eventually a stable build will be released once some more bugs are fixed :D
 

mendus

New member
Hi Shonumi,

I just did a fast test and it looks great! Simple gui and accurate graphics and sound (though I only tested one DMG game).

I noticed that using buttons like A (keyboard) for controls (which I usually do) conflicts with shortcut keys and so they can't be used.

Great work overall! Keep it up!
 
OP
S

Shonumi

EmuTalk Member
Yeah, the shortcut keys need some fiddling with the focus (keep clicking on the main screen). Probably going to get rid of the menu shortcuts (e.g. pressing "F" for to bring up the "File" menu) and just stick with combos (Control + F). Thanks for the feedback ;)
 

Top