It is currently Tue Oct 17, 2017 7:20 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu Dec 18, 2014 10:34 am 
Offline
User avatar

Joined: Mon Oct 20, 2014 1:50 pm
Posts: 92
Most of this fancy-schmancy technobabblewhatsit is way over my head, but I heard the words "graphics" and "replace" and "exceed the color limits" somewhere in there, so this looks like my kind of thing. :D

Once this is all finished and bugtested, I would love to create demo game for you! You can check my signature for some examples of my work and email me once this is finished...Oh, but do you have any ideas in mind of a game that would work well for a demo? Preferably something small so I can polish the game to a mirror shine. :D

_________________


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 11:31 am 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
Yay I helped fix something! Hopefully that is also the solution to palette shifting aka color cycling (or whatever it is... bank switching?) sprites when damaged or getting the star in Super Mario Land 2 as well as screen fading on tiles that is used on screen changes.

Welcome DragonDePlatino! I would suggest a stacker puzzle game for something small. Or perhaps Revenge of the Gator if puzzles aren't your thing.


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 4:49 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19091
Location: NE Indiana, USA (NTSC)
I'm not really familiar with Game Boy homebrew, only NES homebrew. Would an NES game in PocketNES count?


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 4:56 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
@GGuy - This solution only masks the problem of why GBE thinks the two sprites are the same. It still has drawbacks (if the sprite is the same, but uses two different tile numbers at different times, you have one redundant tile that is also mandatory to edit).I still have not figured out the source. I mean, I know what it is doing on a high-level, but the way I am looking at the code says that really shouldn't happen. But since you have ID'ed the bad dumps, I can debug it properly. Using the OBJ palettes is supposed to account for palette changes (where the sprite itself stays the same, but the shades of gray change). But I suspect it is broken atm, for whatever reason. For example, when you get to the 1st warp star in Kirby's Dreamland, you should get dumps for each flashing version. But.. you don't :(

@Dragon - If you want to make a demo, I think it would be great. The only major thing to avoid would be solid colors, unless you don't mind that they can't be properly replaced just yet. Also, avoid crazy midscanline rendering (a la Prehistorik Man). Other than that, be as creative as you want.

@Tepples - GBE should work with (most) GB ROMs. I am not familiar with PocketNES, but if it can run as a GB ROM, GBE can grab the BG and OBJ tiles.


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 5:05 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19091
Location: NE Indiana, USA (NTSC)
PocketNES runs as a Game Boy Advance ROM. It's not for the classic Game Boy.


Top
 Profile  
 
PostPosted: Thu Dec 18, 2014 8:35 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
Okay, thanks for the quick explanation :)

So how feasible would it be for GBE+ (the next iteration of this project, with GBA support) to run PocketNES and replace the graphics? Very plausible, in theory. Replacing graphics in GBA games itself is not a big deal on a technical level. As long as PocketNES uses the tile based modes (Mode 0-2 irrc) dumping and loading is possible based on my current methodology. The same would apply to any.emulation Nintendo themselves made (e-reader NES games) as well as ports (NES Classics) . To GBE+, it would just be another GBA game. Now, the tricky part is to be an accurate enough GBA emulator to emulate a GBA emulating an NES. That would be biggest hurdle; I bet PocketNES is pretty picky about the emulated hardware.


Top
 Profile  
 
PostPosted: Fri Dec 19, 2014 10:00 am 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
I see. Well I guess I am going to stick with the noise chr replacement thing I came up with then. I just need the flashing to work and then I'm set to release graphic packs.


Top
 Profile  
 
PostPosted: Fri Dec 19, 2014 11:20 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
I actually fixed palette changes last night. Just a simple oversight. It totally breaks compatibility though. The standard hashing algorithm is still in flux despite the 1.0 release, so these things are unavoidable. Hopefully I can finalize the algorithm soon. Until then, any changes I make are liable to break existing work.


Top
 Profile  
 
PostPosted: Sat Dec 20, 2014 4:29 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Isn't there any way to convert the old files to the new format?


Top
 Profile  
 
PostPosted: Sat Dec 20, 2014 5:17 pm 
Offline
User avatar

Joined: Mon Oct 20, 2014 1:50 pm
Posts: 92
Eh, incompatibility ain't an issue as long as you back up all of the art you've drawn so far. Really, that's where a bulk of the work goes.

By the way, I decided for the demo I'd like to reskin Kirby's Dream Land. It's a very short game and there characters are tiny so replacing their graphics would be super-simple. But before I draw an entire sheet, can I get a confirmation that something like this would work in your emulator?

Image

_________________


Top
 Profile  
 
PostPosted: Sat Dec 20, 2014 8:52 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
@Sik - Not without knowing the 16-bit salt used to create the final hashes. It's just two bytes (MMIO registers OBJ palettes). You might get lucky if the base hash before salting is 0 (the salt is just XORed onto the hash) or if a game picks two OBJ palettes and sticks to it, then you can derive the base hash easily. But even then there would be no (imo acceptable) way to make a standalone tool for completely automatic conversion.

Otherwise, the emulator could generate both the new and old hash, and if an image file containing the old hash is present copy that file but under the name of the new hash. That works, but feels convoluted to me. The easiest thing to do is accept the limitations of 1.0 graphics packs and just add an option in later versions of GBE+ to hash like the old GBE. It'd literally just be an extra if..else... statement or two, so it isn't a big issue.

@Dragon - Kirby's Dreamland is totally doable. In fact, you're not the 1st (plot twist, it was me: http://m.youtube.com/watch?v=kbd7lGXfRxI) Sorry about the mobile link; blame my phone. As I mentioned, solid colors are inadvisable to edit. To GBE, all instances of that tile are the same whether it's the "sky" or the pause menu background or whatever. There is a way or two around this, but it will be part of GBE+ (GBE's successor, with organized code, a GUI, and GBA support). So for Kirby, I would not touch the sky, but editing the tree's leaves is probably fine. Any tiles that are that same shade and solid (the mountains in the BG in Level 2 for example) will be whatever color you made the tree's leaves in Level 1.

Some good games that you could also try: Megaman I - V, Super Mario Land (Bighead did this), Bomberman GB, Kirby's Dreamland 2 or Block Ball.


Top
 Profile  
 
PostPosted: Thu May 07, 2015 2:56 pm 
Offline

Joined: Fri Oct 22, 2010 1:20 am
Posts: 41
I had this awesome idea for a colorization of SaGa using the Genesis palette. I tried to dump the tiles with GBE but they wouldn't... only the sprites would. The tile dumps output blank images.

While I'm not the author of your emulator, I know enough about this stuff to make my own emulator. I won't... seems like a waste of time when you're so far along. But I will tell you that your approach is flawed. You are abstracting your design to the point of obfuscation. I don't know if this is because of training you've received or because you're trying to apply principles from another field with an integrative approach that's isn't what's actually needed.... That said, why not simply monitor data read from ROM? If ever data from a given address makes its way to the VRAM, you flag the address as the start of a tile. Simple, no?


Top
 Profile  
 
PostPosted: Thu May 07, 2015 4:48 pm 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
Which version are you using tcaudilllg?
I posted an unofficial build earlier in the thread using of the latest source code before Shonumi moved on to the GBE+ emulator that supports GBA. I tested this build with the English versions of the SaGa series (Final Fantasy Legend) and the original Japanese versions and the BGs dump fine. Here's the link to that post if you're using version 1.0 from the google code site. http://forums.nesdev.com/viewtopic.php?f=20&t=11216#p137656


Top
 Profile  
 
PostPosted: Thu May 07, 2015 7:20 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
tcaudilllg wrote:
I had this awesome idea for a colorization of SaGa using the Genesis palette. I tried to dump the tiles with GBE but they wouldn't... only the sprites would. The tile dumps output blank images.


You're probably using a build of the latest master branch. All of that work is naturally experimental, hence you came across a regression. 1.0 dumps them just fine on my end (as does the latest custom-gfx-hd revision).

tcaudilllg wrote:
But I will tell you that your approach is flawed. You are abstracting your design to the point of obfuscation. I don't know if this is because of training you've received or because you're trying to apply principles from another field with an integrative approach that's isn't what's actually needed....


Okay... It would be nice if you could kindly tell me what parts of the code are obfuscated. If you're simply unfamiliar with the codebase, that's understandable. If you think the code is messy (because it is; that's why I'm working on its successor), that's understandable. If you think there should be more comments, that's understandable too. However, I don't see how this approach is too abstracted. It mirrors what other emulators like Dolphin and Mupen64Plus do: generate hashes for graphics, then replace those graphics based on hash matches.

FYI, I have a B.A. in English. Computer Science is not my field. I just like programming and writing emulators as a hobby.

tcaudilllg wrote:
That said, why not simply monitor data read from ROM? If ever data from a given address makes its way to the VRAM, you flag the address as the start of a tile. Simple, no?


What advantage does that offer over waiting for the data to show up in VRAM and reading it there (the way GBE works now)? Ultimately, the data in ROM is going to mirror what's in VRAM. It won't matter what data GBE uses to get its hashes. There's no point in not waiting for the transfer to finish and looking at VRAM for the graphics. GBE only hashes data at the end of a frame (before VBLANK) so the data will be in VRAM by the time the emulator wants to do anything with it. Reading data from random ROM addresses seems less intuitive than looking at VRAM itself.


Top
 Profile  
 
PostPosted: Fri May 08, 2015 3:34 am 
Offline

Joined: Fri Oct 22, 2010 1:20 am
Posts: 41
I was using 1.0.

I was thinking that you'd run into a problem with the hashes. If you fixed that, then I guess there's no issue. Simply, if you trace from ROM, you don't need hashes.

Anyway I'm glad to see this completed. I think it'll be influential.

Edit: nope. The tiles have not dumped with the unofficial version either. The sprites dumped fine. ...Oh wait... I see now. You have to CLICK on the tiles... they don't just get dumped.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


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