Hi, I did a bit of work on MyNes emulator and added a graphics pack feature to it and started making graphics pack for a game(
http://www.romhacking.net/forum/index.p ... 538.0.html).
The code of MyNes is easy to understand but C# is too slow to run the feature and the newer versions do not run at all. And it is very time consuming to manually get the tile info from the emulator. So I'm thinking of making my own emulator in c++ with sdl/opengl and wxwidget and adding tools for making graphics packs.
Instead of PPU rendering the screen by itself, I'm thinking of having the PPU calls another component to do the rendering. Then that component will keep all the calls of a single frame togather and render them all in one go.
I'm also interested in doing the same for audio. So instead of playing a tune, the emulator will play a midi file or mp3.
Do you think this will work?
Hi, I'm now working on the PPU and have a few new ideas:
1. PPU only needs to pretend that it is rendering, doing sprite evaluation etc.
2. PPU calls the rendering engine to render the screen. If certain detail changes mid frame, the PPU will call the engine to finish rendering to the frame and start a new frame section with updated values.
3. I'm using GLSL and I'm thinking of using the depth texture to implement behind BG, sprite priority and sprite overflow.
So if there are many mid-frame changes then it may become too slow. Everytime rendering starts, the engine needs to convert the pattern data into RGBA format. I'm thinking of going through 33*31 tiles and only convert the in use patterns. Or just convert all 256 of them? Keep them between frames? Any ideas?
Why not just convert them when a CHR page is switch by the mapper?
beannaich wrote:
Why not just convert them when a CHR page is switch by the mapper?
Cosmic Epsilon, High Hopes, and anything else that uses bankswitching as a raster effect will slow that to a crawl. I wonder how hard it'd be to implement CHR decoding in a shader. Do modern video cards implement S3TC and palette-textures as a shader or in dedicated hardware?
Or convert the entire CHR data on ROM load and use custom structures as 'pages'. Then all you would have to do is OR the pixels with the current attributes and you're all done.
Depending on the software language and API being used, a pixel shader could be incredibly slow. DirectX with C++ should get the job done
EDIT: It would be interesting to see an entire PPU coded in HLSL, although it wouldn't be able to callback to the CPU for OAM DMA, unless a series of flags and checks were implemented. Still, it would be pretty impressive!
I've heard that idea ~7 years ago, to give old games a whole new look (high res graphics, quality music) while retaining exact gameplay. At the time it was thought to be possible, but wasn't actually made.
I recall another old project,
Pacifi3D. It is emulated Pac-Man arcade with graphics translated to 3D.
EDIT: Or MKWong's Idea works, Audio must be Looped, use BASS with custom plugins for the most compatible music formats.
Enhancing it with any Images should be fine, just use RGBA PNG, a default palette option, but unlike MyNES, size should be 1 pixel for the file, not 2,
A converter from NES/GB/SNES CHR to the PNG for use above is nice also,
-------------------------------------------------
Explanation:
Just make an emulator (and actual PPU later) with:
4k PPU Memory Page $0000-$1FFF, and 4k PPU Memory Page $6000-$7FFF
Defaults the pages for ''Layered'' 8k (instead of 4k) switchable ROM
enable # of 8k CHR ROM Pages
enable 16k default ''CHR-RAM'' memory if no CHR-ROM,
Notes:
If CHR-ROM, Layer extra 4k onto current bank, giving the option of 4bpp or 2bpp.
If CHR-RAM, It is still layered, but it relies on a 16k chip of RAM instead of ROM.
This should make Bankswitching 8x8k MAX (not just the default 8x4k MAX) Switchable, using 16k of CHR memory instead of 8!