What's new

GB Enhanced

chiburunga

New member
Shonumi I have an Idea...
Don't know if its possible, but what if the emulator saves the tiles from the same sprite all together on the same image and the name of the image is the name of all tiles on the correct order so the emu can detect the tiles to be changed?
example, megaman icon uses 4 tiles "x.bmp" "x2.bmp" "x3.bmp" "x4.bmp" the emulator catch the tiles individualy then save correctly in a image called "x1_x2_x3_x4.bmp" so we can edit so much easily and then by the composite name the emulator knows where to divide and put the tiles....

Thanks!

- - - Updated - - -

Another idea...

There are some parts with tiles that have the same name because they are the same, you if possible could do a mode to make those tiles with diferent names acording to position... numbering then for example from top to bottom and left to right... "originaltilename+hisnumber.bmp" so we can do more complex images ;-)
 
F

Fanatic 64

Guest
I doubt it's possible to detect exactly what tiles make up a larger sprite.
 

chiburunga

New member
An easy implementation that would help us all, is to add a number before de texture name incremented while we click to dumb bg tiles.

For example, first tile we click the name of texture will be 001_xxxxxxxxxxxxxxxxxxxxxxxxxx.bmp second tile we click 002_xxxxxxxxxxxxxxxxxxxxxxxxxxxx.bmp and then, when the emulator loads the tile, ignore the underline and what is before the underline....

Maybe if the emulator does not dump sprite tiles aleatory but in a certain order this will help onthe sprites too :)

And if possible add a way to dump the tile already resized 4x would be wonderful!

Sorry for the requests, don't want to disturb you ;-) and sorry for my english, not my native language.
 
OP
S

Shonumi

EmuTalk Member
chiburunga said:
Don't know if its possible, but what if the emulator saves the tiles from the same sprite all together on the same image and the name of the image is the name of all tiles on the correct order so the emu can detect the tiles to be changed?
example, megaman icon uses 4 tiles "x.bmp" "x2.bmp" "x3.bmp" "x4.bmp" the emulator catch the tiles individualy then save correctly in a image called "x1_x2_x3_x4.bmp" so we can edit so much easily and then by the composite name the emulator knows where to divide and put the tiles....

It's like Fanatic 64 said, there's no easy way for the emulator to tell what makes a "large" sprite or a "meta" sprite (a big sprite made up of little sprites). Not every game orders their sprites sequentially, and without analyzing the game code, GB Enhanced can't tell how many sprites a larger sprite is made up of. Even if GB could save, say 4 8x8 sprites that form a 16x16 "meta" sprite, the name of the image file represents that hash of the graphics. Hashes get pretty long, so concatenating 4 hashes would result in a filename with more characters than most filesystems allow.

I see the problem you're trying to address though. The thing is, editing 8x8 sprites and BG tiles was never meant to be easy. Things get much better with the GBC (colors make things pretty distinctive) and things get even better with the GBA (which could natively support 64x64 sprites) but tiny little graphics was what they had to deal with at the time, and that affects people like us trying to make HD graphics for DMG games, unfortunately.

chiburunga said:
There are some parts with tiles that have the same name because they are the same, you if possible could do a mode to make those tiles with diferent names acording to position... numbering then for example from top to bottom and left to right... "originaltilename+hisnumber.bmp" so we can do more complex images ;-)

This is an interesting idea (in theory at least ;)), however it's not something I approve of, simply because it wouldn't work like you think it would. Say we look at the first Tile Map (Tile Map 1) and add the tile number to the hash (tiles are numbered 0 - 255). Say two tiles are the same pixel-wise, but one instance appears at Tile #5, and the other appears at Tile #205. Say we want to have different graphics for Tile #5 and Tile #205, even though the game says they're the same. We then dump these tiles and name them separately with the Tile # in the name. The problem occurs when the game changes scenes or when it scrolls. The Tile Map is basically completely altered. Adding the Tile # to the hash is only specific for the current screen before you. As soon as you take a couple of steps in any side-scroller, the game is already restructuring the Tile Map, changing all of the Tile #s. So in practice, saving the Tile #s as part of the filename/hash wouldn't exactly work if the Tile Map is altered at all. Like I said, it is a novel idea, but because of the way the GB is made, it's not something that could (easily at least) be done.

chiburunga said:
For example, first tile we click the name of texture will be 001_xxxxxxxxxxxxxxxxxxxxxxxxxx.bmp second tile we click 002_xxxxxxxxxxxxxxxxxxxxxxxxxxxx.bmp and then, when the emulator loads the tile, ignore the underline and what is before the underline....

If you're looking for an easy way to order your BG dumps, I recommend that you set your file browser to sort files by Date :p

Not trying to sound negative by shooting down all of your ideas (I really want to listen to any and all input, please don't stop giving it :D). I do however, have something planned out that will make dumping BG tiles MUCH easier, I just haven't gotten around to it yet (really I've been dabbling with my fledgling GBA emulator, tbh :p). Think of it as taking a screenshot of any given moment of the background. All the tiles visible to the user are dumped immediately, but two additional files are generated, a large image of all the tiles arranged in a grid (with spaces and labels) and a text file that has a list of all the filenames that were dumped.

The image-graph would basically goes like:

Code:
0     1     2     3     4    ....
1    (8x8 pixel data goes here)
2    (Evenly spaced to make it readable)
3
4

And the text file would look like:

Code:
0, 0 - 174389dsjaf7qjask2.bmp
0, 1 - dsaf07348dfdsg9fds.bmp
...

This way, you can look at the graph, and say "Hey, I want to edit the title screen of Super Mario Land. Let's see, I'll edit this part first, that's tile 127, 90, which is 73890715j1f807157.bmp", and then you open the file in an image editor. This way you can look at the source image and easily edit BGs all at once.

chiburunga said:
And if possible add a way to dump the tile already resized 4x would be wonderful!

I don't see why not :) btw your English is pretty good (perfectly understandable).
 
Last edited:
OP
S

Shonumi

EmuTalk Member
Yes, I plan to do HD graphics for the GBA. Currently, there isn't much code going on right now. I'm trying to emulate the ARM7 CPU right now, but only a few ARM and THUMB instructions are implemented. I've never tried to emulate a CPU that uses pipelining, and I spent a considerable amount of time last weekend trying to get that right. While my future GBA emulator and GB Enhanced share some similar code already, the GBA emulator will most likely be a seperate project (starting fresh, avoiding certain design choices I don't like in GB Enhanced). If I ever overhaul GB Enhanced's codebase, it's possible the two might be merged, but this is all a year or two down the road. We'll see what happens.

Anyway, my current focus is actually to try to clean up some of the bugs in GB Enhanced before I get back to work on improving HD and custom graphics. I thought I was clever finding a way to reliably emulate the APU without being cycle-accurate (or even semi-accurate) but several games are making it apparent I need a new approach. There's also the matter of proper DMG sprite priorities.
 
OP
S

Shonumi

EmuTalk Member
Nope, not really :p Merging HD Custom Graphics is on hold atm chiefly because getting GBC games to act correctly is an involving process (one that I haven't even started yet)

The latest master branch revisions can correctly boot from the GBC BIOS now though:

iytQLW4c431AS.png
ib2tUYpSU4xdgn.png
ipBCr8AASdVMS.png


It's a small change really. I haven't been working on GBE a lot recently (playing video games mostly, I admit it).
 
OP
S

Shonumi

EmuTalk Member
Not really an update, but I have finalized a working theory for successfully dealing with custom graphics (HD or 1:1) for GBC titles. As I said, the biggest issue is the fade in/fade out effects, which would technically generate hundreds and thousands of different graphics simply because the palettes vary while the actual "pixel data" is basically the same. Not to bore anyone with the details, but it involves calculating hue ranges and dynamically adjusting the brightness of custom graphics. It should handle almost any situation the GBC can throw at me, but we'll see what happens when the code starts running. Nothing written yet, but the theory was really the biggest stumbling block. No plan of attack means nothing got done, so that's why development may have seemed to suddenly "languish". Hopefully things will be busy here in the next few days.
 

Danny

Programmer | Moderator
[MENTION=110864]Shonumi[/MENTION]: How is the project going buddy?
Was impressed with what I have seen thus far!
 
OP
S

Shonumi

EmuTalk Member
This project is doing great. So great, in fact, it's dead :D

I'm half-joking of course. GBE will not be worked on (not by me) because GBE+ will be everything the original project was and more. GBE+ will basically feature everything present in this thread plus more (GBC support for customized graphics, a GUI, GBA support). I've been on hiatus to work on GBE+, specifically a ton of GBA stuff.

I know people are wondering what happened to me, so the answer is I really didn't go anywhere. I love the idea behind GBE, and I just want to make it better. The biggest problem for custome graphics has been the lack of a GUI. I don't know how people like Bighead put up with me. Eventually (once GBA emulation is mature enough, likely before this summer) I'm going to start merging and reforming the GB/GBC code into GBE+. I have to make enough abstraction so that the emulator can handle all three systems without needing to be 3 projects mashed together (and since I really, really want to pursue DS emulation, I would like to see if I can make a 4-in-1 handheld emulator).

If you want you can check out my progress on github (https://github.com/shonumi/gbe-plus) Currently tackling the GBA Special Effects (alpha blending, brightness increase, brightness decrease). Things are going alright, a bit slow this month, but I'm making headway. Thanks for the interest. Keep programming emus yourself, alright ;)
 

Danny

Programmer | Moderator
This project is doing great. So great, in fact, it's dead :D

I'm half-joking of course. GBE will not be worked on (not by me) because GBE+ will be everything the original project was and more. GBE+ will basically feature everything present in this thread plus more (GBC support for customized graphics, a GUI, GBA support). I've been on hiatus to work on GBE+, specifically a ton of GBA stuff.

I know people are wondering what happened to me, so the answer is I really didn't go anywhere. I love the idea behind GBE, and I just want to make it better. The biggest problem for custome graphics has been the lack of a GUI. I don't know how people like Bighead put up with me. Eventually (once GBA emulation is mature enough, likely before this summer) I'm going to start merging and reforming the GB/GBC code into GBE+. I have to make enough abstraction so that the emulator can handle all three systems without needing to be 3 projects mashed together (and since I really, really want to pursue DS emulation, I would like to see if I can make a 4-in-1 handheld emulator).

If you want you can check out my progress on github (https://github.com/shonumi/gbe-plus) Currently tackling the GBA Special Effects (alpha blending, brightness increase, brightness decrease). Things are going alright, a bit slow this month, but I'm making headway. Thanks for the interest. Keep programming emus yourself, alright ;)

Interesting! Thanks for the detailed explanation.

I'm looking forward to hearing updates on the new project.

Also thanks for the words of encouragement :) I haven't had time to work on my Space Invaders emulator this week, due to programming like a mad man at work... But am planning on resuming work on it this weekend.

Thanks again for the informative read :D
 

LyonHrt

Dcemu.co.uk guy
I see from git you've done quite a bit of work this week on GBE+ anything interesting progress? I have to admit i've yet to do anything with gbe, but be exciting what you can achieve expecially in the customised graphics department on gbe+ and cant wait to get my hands on a compiled version :)
Certainly will be supporting this from early on.
 
OP
S

Shonumi

EmuTalk Member
Yup, a lot of work is going into the process of integrating old GB/GBC code with the new GBA code. It's easy enough to make the two sides play nice in a single emulator, but GB Enhanced was my first attempt at making a program of this sort. A lot of the previous code needs to be updated to conform with a new codebase along with various minor tweaks. LCD emulation and custom graphics need large portions rewritten, but it shouldn't take me too long. The biggest change by far will be a proper GUI. You won't believe how easy and helpful this will make working on custom graphics.

I'm just beginning, and there's plenty of stuff yet to do, but I'm confident I'll get something done soon :D
 

LyonHrt

Dcemu.co.uk guy
a good gui would certainly improve things, i was playing with gbe earlier actually with tiles and sprites which i had done for hdnes, and its a very capable emulator, the only thing that was missing, would be individual folders for each sprite pack, maybe based on rom name.

Custom graphics with gba will be very fun, working with 16bit graphics should bring out a lot of games.

- - - Updated - - -

You can do alot with gbe, theres some really nice looking games such as warioland, bring them into colour and 4x size and they're probably going to look next gen!
 

Attachments

  • Untitled-2.png
    Untitled-2.png
    32.6 KB · Views: 574
OP
S

Shonumi

EmuTalk Member
Say wha? Looks great man :)

I'm honestly surprised people can actually use GBE as it is now (Command-line only? Drag and drop to start ROMs? Editing text files for configuration?) It was my first real attempt at emulation, and it shows. But things will improve, no doubt. Setting up per-game folders for loading graphics is definitely something I can add, quite easy in fact.

One thing that requires more attention, though is the issue of solid colors. As you can see, the gray at the bottom and the gray in the sky (1st 8x8 pixels under the HUD) at the same. To the game, they're the same tile, and GBE currently thinks they're the same as well. I've got some crazy schemes in mind to eliminate the problem, I just need to make them user friendly somehow. GBC and GBA games tend not to suffer this sort of problem because they have more colors to work with, making tiles more unique.
 

LyonHrt

Dcemu.co.uk guy
Sounds wonderful, and i don't really knock command line, always worked for mame, and look how many front ends are, so its not a big issue, just really an external gui that would write to ini
And yeah i could see that myself about the pallete, the plain tiles big problem, but no more than with nes.

Though to solve the dumping/loading problem, what about just a key press to switch one to the other whilst its running, or would that result in unexplained results?
 

Top