Acmlm's Board - I2 Archive - Rom Hacking - Xtreme graphics NES demo
| User | Post |
HyperLamer
Posts: 6091/8210 |
I have to agree with Disch. The point of emulation is to do things exactly how the real system does them. If you make an NES emulator that can render 3D models and run a billion instructions a second, even if it does run NES games, it's no longer an emulator. It's a scripting engine that's NES-compatible. Your games won't work on any other emulator, let alone a real NES; you may as well be making a PC game.
Now if you can find a way to do these things on a real NES (and no fair replacing the CPU/PPU; addons/cart tricks only  ), then sure, go ahead and put them in emulators. The point, though, is that an emulator does what an NES does, so if an NES can't do it, neither should an emulator. (This of course doesn't apply to useful things like save states and frameskip, because these features are transparent to the game; you can't design a game that relies on them or even knows they exist.) If a game does one thing on an emulator, and a different thing on an NES, the emulator is defective. |
Dish
Posts: 470/596 |
Aha, yes I could see that. Nice catch BMF |
BMF98567
Posts: 1005/1261 |
Originally posted by Disch
- only one Background -- no multiple layers
Actually, I *think* there is a way to feed video into the expansion port and display it in place of the background color, but that would require a stupid amount of hardware on the cart, as well as an expansion port adapter connected to said cart, so uh...never mind.
(Actually, I believe Nintendo was planning just such an adapter for the US NES to get expanded sound out of the MMC5, since the carts' sound output is routed to a pin on the edge connector that goes to the expansion port. The adapter would just connect the sound IN and OUT pins together on the expansion port.) |
Dish
Posts: 464/596 |
Originally posted by beneficii
Oh, there's no way to trick the NES into masking the bits in one table with the bits in the other?
Not without modifying the system.
For each rendered tile (8x1 pixels), the PPU makes 4 reads from the cart:
- 1 nametable byte
- 1 attribute table byte
- Pattern Table byte A (low bitplane)
- Pattern Table byte B (high bitplane)
A few cycles later... the bitplanes have their bits shifted out and rendered. The cartridge cannot interrupt this process at all, no matter what kind of wacky hardware it has (unless it can like short out the system or something crazy like that). The best it can do is change the state between each of these fetches. Like I said, that's kind of what MMC5 does -- it feeds a modified attribute byte and different pattern table bytes where it feels appropriate (that's how it does things like extrended attribute mode, and its vertical split screen effect)
But no way, no how are you getting more than 4 colors per 8x1 pixel tile. You could overlay a bunch of sprites one top of each other to get a lot of color depth (sort of like having the sprites act like different graphic layers)... but as mentioned before... you can only have 64 sprite pixels per scanline -- so that will only work to a point. |
beneficii
Posts: 336/567 |
Originally posted by Disch
Schpune is my emu -- although that "PL6" build is the joke build for the XTREME demo. The PL6 build will run other games normally though.
As for your proposal:
B: allow 4-bits per pixel -- this is beyond what the NES can do. You're stuck with 2bpp. The best you can do is change/replace the palette/attribute data between tile fetches (that's kind of what MMC5 does in ExAttribute mode)
E: make CHR-ROM directly writeable -- ROM (aka Read Only Memory) is, by definition, not writable. I fail to see why you'd want to do that anyway... or maybe I'm just not understanding?
Well, for that latter one, I heard vaguely something about making it writeable (I think it gets its name changed to VRAM or something when that happens), for certain animations, but let's quietly drop that subject. 
Oh, there's no way to trick the NES into masking the bits in one table with the bits in the other? |
Dish
Posts: 463/596 |
Schpune is my emu -- although that "PL6" build is the joke build for the XTREME demo. The PL6 build will run other games normally though.
As for your proposal:
B: allow 4-bits per pixel -- this is beyond what the NES can do. You're stuck with 2bpp. The best you can do is change/replace the palette/attribute data between tile fetches (that's kind of what MMC5 does in ExAttribute mode)
E: make CHR-ROM directly writeable -- ROM (aka Read Only Memory) is, by definition, not writable. I fail to see why you'd want to do that anyway... or maybe I'm just not understanding? |
beneficii
Posts: 335/567 |
I would too. BTW, who made Schpune?
Anyway, would something like I outlined in my proposed mapper be feasible? |
Dish
Posts: 462/596 |
Originally posted by Dr. Mario
You DO know that an NES is capiable of 16-Bit graphics right?
That depends what you mean by 16-bit graphics. The PPU is limited to 2bpp tiles any way you slice it. However you can alter the PPU state between tiles to change which colors are drawn and when.
The NES cannot display any colors other than those in its "rigid" palette. Well those colors and the variations by the color emphasis bits. The only other real restriction in its graphics output is that each output tile graphic uses the same attribute byte. So each 8x1 pixel area on the screen will be restricted to 4 colors -- however which colors can be changed at any time by the cart assuming it has the hardware to do so.
So yes you can have very detailed graphics on the NES without system modifications. However no matter how beefed up your cartridge hardware is, you're STILL restricted to the following:
- each 8x1 pixel area on the screen cannot have more than 4 colors
- you cannot output any colors not in the NES's palette. You're limited to the 64 colors it gives you (or really 512 if you count all the color emphasis combinations)
- only one Background -- no multiple layers
- no more than 8 sprites on any 1 scanline (maximum of 64 sprites pixels rendered on any one scanlnie)
I'm also aware that on the Famicom, since the sound is run through the cartridge, you can also have very high quality sound (potentially much higher than 44KHz). However you are restricted to mono -- no stereo.
I'm aware of the Color Dreams "Hellraiser" cart.
Reguardless, the NES can do a lot more than you think.
Nah... I'm well aware of what it can do. And what it can't do.
Originally posted by beneficii
Well, it's just that it's not NES, so I don't know if it can be valid
Yes, I know. I was sort of trying to show how ridiculous/problematic some views on emulation are. If something like this XTREME demo were to actually be serious, I would be very, very upset, since it goes against everything emulators try to accomplish. However as a practical joke I think it's pretty funny. Hilarious in fact XD |
beneficii
Posts: 334/567 |
Originally posted by Disch
I would've thought you would be happy with this development. I mean it allows for better graphics! Isn't that what you were after?
Well, it's just that it's not NES, so I don't know if it can be valid.
Now, in response to Dr. Mario's comment, if someone can make a mapper that allows for this and can get it to work on the real NES, then I would change my view.
EDIT: Perhaps, something based on the MMC3? Behold, the MMC7!
$8000 write
FCxx xLLL
F: Do EOR $1000 for CHR-ROM bank swap
C: Have fixed banks be at $E000 and $8000 instead of $E000 and $C000
L: if following value:
0 - swap 2k bank to CHR-ROM $0000
1 - swap 2k bank to CHR-ROM $0800
2 - swap 1k bank to CHR-ROM $1000
3 - swap 1k bank to CHR-ROM $1400
4 - swap 1k bank to CHR-ROM $1800
5 - swap 1k bank to CHR-ROM $1C00
6 - swap 8k bank to PRG-ROM $8000 (or $C000, depending on fixed)
7 - swap 8k bank to PRG-ROM $A000
$8001 write
BBBB BBBB
B: Bank to swap to $8000 write
$A000 write
xxxx xxxM
M: mirroring (0=vertical, 1=horizontal)
$A001 write
xxxx xxVS
V: allow writes to SAVERAM
S: enable SAVERAM ($6000-$7FFF)
$A002 write
xxxx xxB4
B: allow 4-bits per pixel (will use nametable that would normally mirror it--i.e., if vertical, the one above it, if horizontal, the one below--4-screen mirroring must be enabled!)
4: allow 4-screen mirroring (required for space for the extra pixel bits, if allowed)
$A003 write
xxxx xxxE
E: make CHR-ROM directly writeable (through $2006/$2007, of course)
$C000 write
CCCC CCCC
write IRQ counter here
$C001 write
write any value to copy the IRQ counter from $C000 to $C001 so it can begin
$E000 write
write any value to disable the IRQ counter
$E001 write
write any value to enable the IRQ counter
Tell me how feasible this is. |
Dish
Posts: 461/596 |
I would've thought you would be happy with this development. I mean it allows for better graphics! Isn't that what you were after? |
Dr. Mario
Posts: 224/262 |
Cute. Remind me to agree with you all the time from now on.
**EDIT**
You DO know that an NES is capiable of 16-Bit graphics right? I mean, I don't want to blow your mind or anything, but with a little extra hardware, third party compant Color Dreams made a prototype of a 16-bit Hollraiser game. Due to production costs and Nintendo not letting it get released because of the new hardware it never saw the light of day though. Reguardless, the NES can do a lot more than you think. |
bbitmaster
Posts: 88/103 |
Wow, with your special emulator, you've basically mutated the nes into something far more Xtreme.
Forget custom palette hacks. I can't imagine how many new hacks with amazing graphics this could bring about. Way to go Disch!
|
Dish
Posts: 460/596 |
I figured that would happen. I'm [hopefully] getting some new webspace now. New links to come.
EDIT -- original post updated ^^ Problem solved |
beneficii
Posts: 332/567 |
Putting this in Nintendulator, will get back to you on it....
Hey, Disch, can you like upload it to a different site? You exceeded your bandwidth limit. Or perhaps you can e-mail me?
Oh, well, upon further reading it wouldn't work on the real NES. I just don't see the point. |
Someguy
Posts: 357/397 |
That's amazing, but what is this feature and how does it work? What are the limits? Does it only allow single images or could it be applied to a game in real time? Should we just forget about the SNES entirely if with the right stuff NES emus can support this and CD quality sound?  |
Dish
Posts: 459/596 |
I just finished work on an NES homebrew demo which shows off the XTREME capabilities of the NES. The download is available here:
http://elazulspad.net/disch/xtremenesdemo.zip
Like I said, this shows off the XTREME graphical capabilities of the NES. Here is a screenshot of the demo in progres:
This is not a fake screenshot. Download the demo if you don't believe me
This demo uses an emulator feature which has not caught on in some emus. One emu which supports it is the PL6 build of Schpune:
http://elazulspad.net/disch/Schpune_PL6.zip
Rather than show jarbled graphics, the game will detect emus which don't support it and will give an error message.
This demo will not run as expected on a real NES. But do you think I really care if it would run on an NES? I don't have the resources to make a demo run on an NES so it's no sweat off my back. I enjoyed doing the graphics for this demo. If I see an oppotunity to make my graphics look better then I'm going to take it.
Coming soon -- XTREME sound demo. Witness CD QUALITY sound coming from your NES*! Stay tuned!
*NES emu only, not actually the NES system
EDIT:
links updated -- no more geocities |
|
hukka
