LyonHrt
Dcemu.co.uk guy
RxNES has updated to v3.021. This release is an important update, and fixes the issue of generating gigs of data, due to constantly making new textures, where as now it now replaces existing textures, so should be reduced to a more manageable 500meg of ram.
This release also fixes issues to general emulation script RxEnhance.cs, which was getting confused in some rom emulation.
Also a call out to anyone who'd like to help with this project:
You can download directly here.
This release also fixes issues to general emulation script RxEnhance.cs, which was getting confused in some rom emulation.
Also a call out to anyone who'd like to help with this project:
As you should know the main Enhancement script RxEnhance.cs is editable in a text/c# editor, and hopefully a user can optimize / improve it further and share with everyone else.
The sprites are rendered on their own layers, 1 layer for each of 4 screen palettes.
they are then cropped out for dumping.
This is the wrong approach, and sprites should be read from the cartridge and not from the screen; (but I spent weeks coding it this way). Problems arise when 2 sprites overlap each other and they dump combined and overlapping (Only if they use the same of 4 palettes).
Some sprites dumped are duplicates yet have different file names, cropping is over-cropped.
I dunno, I did my best effort on everything but I was really hoping for help from the community.
Lots of good things! The emu has tons going for it!
I just wanted to mention the bugs I would like to see fixed by users as I don't have a current interest in fixing them ('cause it doesn't run full speed).
Important to remember is that replacement graphics can be bigger than their original screen space, so the over-cropping issue shouldn't even matter if ppl are replacing the graphics with new ones anyway. The issue that remains is the corrupt sprites, if a sprite dumps at the same time as the nes is rendering it, it will be half and half of a frame and the frame before. This would cause the replacement sprite not to be used and the corrupted / incomplete sprite to flicker on.
Also, a good point, is that any .png can be replaced with a .obj 3d model. (For sprites and BG Tiles) Just make the .png trasparent and name the .obj the same hash fliename as the .png. The exact way it works is in the code and i'm just still waking up this morning.
I guess this is a call out to Unity3d coders to have a look at the RxEnhance.cs script and see if they can improve it. If you could with the release of this version, write up a call to coders to have a look and fix up the main script. (It compiles at Runtime )
The sprites are rendered on their own layers, 1 layer for each of 4 screen palettes.
they are then cropped out for dumping.
This is the wrong approach, and sprites should be read from the cartridge and not from the screen; (but I spent weeks coding it this way). Problems arise when 2 sprites overlap each other and they dump combined and overlapping (Only if they use the same of 4 palettes).
Some sprites dumped are duplicates yet have different file names, cropping is over-cropped.
I dunno, I did my best effort on everything but I was really hoping for help from the community.
Lots of good things! The emu has tons going for it!
I just wanted to mention the bugs I would like to see fixed by users as I don't have a current interest in fixing them ('cause it doesn't run full speed).
Important to remember is that replacement graphics can be bigger than their original screen space, so the over-cropping issue shouldn't even matter if ppl are replacing the graphics with new ones anyway. The issue that remains is the corrupt sprites, if a sprite dumps at the same time as the nes is rendering it, it will be half and half of a frame and the frame before. This would cause the replacement sprite not to be used and the corrupted / incomplete sprite to flicker on.
Also, a good point, is that any .png can be replaced with a .obj 3d model. (For sprites and BG Tiles) Just make the .png trasparent and name the .obj the same hash fliename as the .png. The exact way it works is in the code and i'm just still waking up this morning.
I guess this is a call out to Unity3d coders to have a look at the RxEnhance.cs script and see if they can improve it. If you could with the release of this version, write up a call to coders to have a look and fix up the main script. (It compiles at Runtime )
You can download directly here.