Hi, I recently resumed working on my emulator and now I think I have enough to show. The gimmick of the emulator is the ability to display custom true colour tiles at up to 4x resolution.
Link:
See the attachment of the third message
BombSweeper is used as an example and a simple 2x graphics pack is included in the files which replace the number tiles. You need to download and put BombSweeper.nes inside the rom folder. You can play around with the png files inside the BombSweeper folder and see the results. The emulator is still in early stage and so lacks many standard features. Please read the readme for the limitations before using it. Feel free to comment and please let me know if you have trouble running the emulator on your machine.
Thanks.
Heh... I have almost the exact same idea for my emulator. Looks like you beat me to it.
The download link seems broken though.
Please use the attachment feature of the forum.
A demo with SMB
http://youtu.be/N57ApspYHVE A quick run of Kung Fu
http://youtu.be/yySSNxkQ4Q8The intro of Dragonball Z
http://youtu.be/uC73qM8YPPEThe intro of Dragonball Z II
http://youtu.be/ju-9yREPnn8The first few stages of Nuts & Milk
http://youtu.be/gwORJNKOoqkGitHub
https://github.com/mkwong98/HDNesHere are the files. (Updated 24-2-2015)
Result:
Code:
pino@pino-laptop:~/Desktop/hdnes$ wine hdnes.exe
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0080: stub!
fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0001: stub!
fixme:wgl:X11DRV_wglChoosePixelFormatARB unused pfAttribFList
wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger...
A backtrace was produced; I'm attaching it.
I tried to load 2 ROMS, only showed the background color. Didn't let me assign keys. None of the tabs had any info. Size change didn't change window size at all for some reason. And no Y where there's an X in the screen change thingy...so I don't think I can provide any info on the emulation it's self as...yeah, it didn't work here. Win7 Home Prem., AMD Turion 2.5Ghz dual core, 4GB RAM, HD4250 Mobile GPU.
It works ok for me until I tried to close the program and not even windows task manager itself could do the job...
Thank you for your feedbacks.
I forgot to say in the readme that pressing the esc key to close the game window.
I'm getting a null pointer exception when I run the program. It's jumping to address 00000000 at some point.
I'm using VC++ 2010 Express. Maybe need to install the redistributable package?
http://www.microsoft.com/en-us/download/details.aspx?id=5555
It runs through the GUI, then when you start the game, the emulator window appears, but it crashes before any frames are rendered.
Using Windows XP. I'm sure it's not an issue with the redistributable, otherwise it wouldn't start at all.
Dwedit wrote:
when you start the game, the emulator window appears, but it crashes before any frames are rendered.
Using Windows XP.
That's the same misbehavior I saw on Wine.
Looks like something failed to initialize and return 0 and I didn't check it.
What OpenGL version can your machine support?
mkwong98 wrote:
What OpenGL version can your machine support?
I don't know. It's a Dell Inspiron mini 1012. What command should one use to determine the supported OpenGL version?
Try GPU Caps Viewer
http://www.ozone3d.net/gpu_caps_viewer/What screen resolution are you using? Maybe the program is asking for a surface larger than available size. It is using 1024*720.
Can you post before/after screenshots of Bomberman running under HDNes?
I'm not using Bomberman as an example. It is Bombsweeper, a free NES rom. So every one can try it without any copyright problem.
I'll post some screenshots tonight.
Which free picture hosting site do you recommend?
Or just the attachment button right here.
Here are some screenshots
...Think just one of those screenshots would have done. Thanks.
Check the score text on the top compared to the bottom.
And why is the bomb missing the 2nd sprite?
Thanks for asking! I didn't notice that before. Turn out my program has problems when sprite is exactly on the edge of the screen.
The problem is fixed and I updated the attachment and the screen shots.
I also finished the GUI for the screen resolution and input settings.
The screen resolution sometimes has problems if it is not a multiple of 256x240.
Now I'm having trouble with the title screen of Zelda. The waterfall looks wrong and the title screen has the flickering on the top right. Any suggestions?
Turns out there are too many sprites on the screen at the same time and I have a buffer overrun. Now I have problems with mapper 1 games with chr rom. I think my bank switching code is wrong.
Mapper 000 - 003 games are now playable and battery back up supported.
1-4-2013
Graphics pack editor is now usable
2-4-2013
i ) Fixed severl bugs
ii) Save state function added
I tried the new version. I can't get it to do anything. Does it require a newer version of Windows than Windows XP? It crashed as soon as I pressed "Start game". (Just after it tried to create a "SDL_app" window. )
Did you use the old version before? A new 'edit' folder is added to the new version and it may crash if the folder does not exists.
6-4-2013:
1. Added support to some MMC3 games.
2. Improved playing of CHR RAM games.
13-4-2013:
1. Fixed incorrect tiles in MMC3 games (SMB3 map screen)
2. Fixed a out of range PRG address in MMC3 (TMNT-TF)
3. Fixed incorrect path for game save files
4. Fixed a slow down bug
5. Update the game save file when closing the game instead of closing the program
6. Little speed up for repeating background tiles
7. Added support to Bandai FCG boards games.
Many thanks to Quietust for helping with EEPROM of Bandai FCG board
Tip of friendly advice:
When releasing software publicly, do not get into the habit of saying "Many bugs fixed" or "Bugs fixed" as part of your ChangeLog -- it does not instil confidence. Itemise/list off every bug you fix.
Thanks for the tip. I'll fix it.
koitsu wrote:
Tip of friendly advice:
When releasing software publicly, do not get into the habit of saying "Many bugs fixed" or "Bugs fixed" as part of your ChangeLog -- it does not instil confidence. Itemise/list off every bug you fix.
Fixed a few other bugs that I don't remember. Cosmetic changes in the GUI.
14-4-2013:
1. Added "All" to screen shot combo box on the "Graphics Pack Editor" page. This will show all tiles.
2. The tile list is now ordered by tile ID.
3. Reduced the size of the auto generated images. Having too many tiles on one image makes it difficult to see and choose the correct tile.
4. Change the screen shot format to PNG to reduce the file size of the data generated for the graphics pack editor.
Please note that now using data generation may cause slow down to the emulator. I'm using wxImage to save it in PNG format. Any suggestions of faster way of doing this is welcome.
Also if you have generated some data using previous versions, you must convert all BMP files inside the "edit" folder into PNG before using the graphics pack editor. I used batch conversion of IrfanView for this.
This is very exciting! For a long time I've wondered how difficult it would be to implement higher color and display resolutions on the NES.
I downloaded the emulator but couldn't figure out how to get the high res images to appear for BombSweeper.
Also, I can't close the program using the Windows close icon. I have to force it to shut down using Task Manager.
URL for downloading it?
EDIT: Oh, it's
here.
Thank you for using the emulator!
You can press ESC key to close the game.
I haven't updated the Bombsweeper graphics pack for the later versions of the emulator, so it is not included with the download. Now that the editor has most of the functions I wanted, I will update the pack shortly. Then after downloading the pack, the pack must be placed in the same directory as the rom file and has the same name as the rom file.
To make your own HD graphics pack, check the "generate data" option and play the game as normal. The emulator will record all the tiles and colors used during the gameplay. Then the easiest way is to go to the graphics pack editor, select a scale factor and click the "auto generate" button. The emulator will dump all those tiles into image files with correct connections. Now go to the rom directory and look for a sub directory with the same name as the game. The generated images will be inside there. You can edit the image files and your changes will appear when you play the game.
Thanks, I'll give it a try.
15-4-2013:
1. Fixed a bug with the "cancel selection" button on the graphics pack editor page.
2. When showing a box around the selected custom tile, the box is not visible if it is on top of transparent pixels. Now it is always visible.
3. Updated the BombSweeper graphics pack to the latest version and added it to the download. To use it, copy it from the rom directory and paste it into the actual rom directory. The pack is designed for 4x scale display.
I tried following your instructions to generate graphics for The Legend of Zelda but I couldn't find any image files in the subfolder that was created for the game. I checked "Generate data..." on the Video tab, set the screen size to 4x, started the game, played for a couple of minutes, then went back to the Graphics Pack Editor and clicked "Auto generate." Nothing happened. Then I exited the game and tried the same thing but it still didn't work. Am I doing something wrong?
This is quite cool! Great work!! =D
Do you have graphics packs for any other games?
don't be a fag, play nes like a man, play nes at nes resolution, period
all these silly filters are plain fugly in addition of being untrue to the real nes experience
koitsu wrote:
Tip of friendly advice:
When releasing software publicly, do not get into the habit of saying "Many bugs fixed" or "Bugs fixed" as part of your ChangeLog -- it does not instil confidence. Itemise/list off every bug you fix.
Haha! I am way guilty of this.
Zelda is a chr ram game so you need to uncheck the last option as well. But if the game modify the tiles before showing it on screen or read other prg data before sending it to chr ram then that option will show incorrect tiles.
I'm making one for SMB as a test.
X-or wrote:
don't be a fag, play nes like a man, play nes at nes resolution, period
all these silly filters are plain fugly in addition of being untrue to the real nes experience
I might say "agreed", but that's NOT the purpose of this emulator, so... you're history.
X-or wrote:
don't be a fag, play nes like a man, play nes at nes resolution, period
all these silly filters are plain fugly in addition of being untrue to the real nes experience
Yes, because that hasn't been done to death. There's literally hundreds possibly thousands of NES emulators existing in some form or another. I think it's cool that he's trying something new. Also, this isn't a "filter" ala HQ2x, it's a method for replacing graphics using graphics packs. Also, some of us may take offense to the word "fag" being used in a derogatory manner. I would suggest not posting again unless you have something constructive to say. Thanks.
You didn't tell me anything I didn't know, I'm just saying playing nes with so called "enhanced" graphics is just pointless. If you want to enhance a game, then enhance its gameplay, not just its graphics, rebuild it entirely from scratch. Changing just the graphics is entirely vain.
And btw you're one thousand years too young to lecture me little padawan.
I'm so disappointed that you guys couldn't resist feeding it.
The flames and namecalling (I would classify it as trolling) needs to stop. If I see it happen again I will be temporarily suspending accounts.
Folks are free to have an opinion, and X-or's opinion is fine (I actually share his opinion on this matter, just not so rudely), but there's absolutely zero point to showing up in a thread with the sole purpose of starting shit with people. The last thing this forum needs is trouble of this sort, as it often today escalates into something much worse. Please don't let that happen.
Consider this a public warning.
Big deal! *panicking*
But yes I must admit it was pretty rude. I guess I overreacted after seeing yet another one (the straw that broke the camel's back) of these annoying "emulation" news about some vainglorious graphic filters. I did not come to just start shit, I'm stating my opinion and reacting to this long filtering trend, is all. No trolling there, just different opinions stated a bit roughly, I you can't take that, you need to man up a little.
Okay, I downloaded hdnes.7z and attempted to run the BombSweeper game, but all I get is a black screen. I tried unchecking the graphics pack option to see if that was the problem, but it's still black. I can hear sound in response to my kepresses so I know the game is running, but I can't see anything. (I tried some other ROMs, same problem.)
Anyone else have this problem?
I think X-or is focusing on the NES part of emulation and I'm focusing on the game part of the emulation.
Maybe I should say this from the very beginning: I make this emulator for fans to express their love for their fav games. Some people do this by speed running the games, some by making a LP for the games, some by translating the games, rom-hacking, writing a walkthrough, make a website etc. However, not everyone have that kind of skill. And on the N64 emulator or PC, people can also make graphics pack for the games, much like adding a custom paint job to their fav car. And this is how I want my emulator to be, another way for the fans to express and share their love for the games.
X-or, I apologize if you feel offended because I make an emulator to deviate from a real NES on purpose. I do respect your love for the NES and I hope you can understand my point of view. Thank you.
rainwarrior, I think the OpenGL started, but the GLSL code has problem running. Which OpenGL version or graphics card are you using?
I am running Windows 7 64-bit with an nVidia GeForce GT 540M. I don't know what you mean by OpenGL version.
Is there a log somewhere that would output a diagnostic error about the shaders?
That graphics card should be more than enough. I really need to add an error log to the emulator.
18-4-2013:
1. Fixed a bug that display a wrong tile ID after clicking "Cancel selection" button.
2. Added error log function for initializing the video. The log file will be located inside the log directory.
Don't get discouraged by the naysayers. Fortunately for them there are already many emulators available that provide a traditional NES experience.
Providing support for more colors and a higher resolution is a very cool idea that many will embrace. Have you considered publishing a standard for how the increased colors and resolution are implemented? This way other emulators could eventually adopt it and people would be more likely to create graphics packs.
Ok, the log just says "failed to link shader program" three times. Probably you're going to want to log which shader, and the error string from the shader compiler.
Also you removed the BombSweeper.NES from the roms folder?
Thank you for the reply. I was cleaning up the release folder and removed the rom by mistake. The emulator uses three shader programs spr back, background and spr front, so none worked. I'll add more detail to the log. Thanks.
21-4-2013:
1. Added more detailed log for GLSL errors.
2. Replaced some deprecated code in GLSL.
rainwarrior, sorry to keep you waiting. I think nVidia is more picky with versions and deprecated features, so I updated the shaders. Please, can you try it again? Make sure to replace the files in the shader folder. Thank you.
nesguru, thank you for your encouragement! The graphics pack has the following rules:
1. A folder with the same name as the rom file inside the same directory.
2. Image files in PNG format in the folder. All pixels which are not fully transparent are treated as fully opaque.
3. A text file named "hires.txt" in the folder.
4. The text file contains lines of text and each line begin with a tag surrounded by "<" and ">".
5. A "scale" tag is followed by a number, which defines the scale factor of the pack. Valid values are 1, 2 or 4. If this tag does not exists, the default scale is 2.
6. A "img" tag is followed by the file name of an image file.
7. A "tile" tag is followed by 8 values separated by comma.
8. The first value is the tile ID in decimal. This is the distance between the first byte of the tile and the beginning of CHR ROM, or the beginning of PRG ROM if it is a CHR RAM game, divided by 16. The data of a 16 pixels tall sprite is counted as 2 tiles.
9. The second value is the index of the image which contains the replacement graphics, also in decimal. The first image listed in this file has an index of 0 and the second image has as index of 1 and so on.
10. The next three numbers are colors of the palette used by the tile, in decimal. The ordering of the 3 colors is significant and each tile can not have multiple replacement tiles for the same colors and ordering.
11. The next 2 numbers are the x coordinate and y coordinate of the top left corner of the replacement tile within the image, measuring from top left corner of the image, in decimal.
12. The last value indicates whether this replacement tile is used as the default(Y) or not(N). If the emulator renders a tile and cannot find a replacement with an exact match (tile ID and 3 colors), then the emulator will use the default tile with a matching tile ID. Each tile can not have more than one default replacement.
I had the same problem, but the log has three of these:
Code:
Failed to link shader program
Interpolation of texcoord does not match
in vertex and fragment shaders.
Really easy to fix with a
smooth in your fragment shaders. So, I did that and now it's working fine.
My next suggestion is that if there's a shader error you should print the name of the shader as well.
Thank you for fixing that!
I'm very happy to know about this project!
Are you planning to make graphics replacement easier on future versions? I tried to change 'Batman' title screen with no success.
I still have to adjust/ move / resize tiles to get an accurate 2x title screen - but my goal was to have something like this:
I would love to change NES graphics using tools similar to HiSMS emulator.
HiSMS is so easy to use that even a newbie like is able to achieve good results (like
http://www.youtube.com/watch?v=FeegmIt03nM and
http://www.youtube.com/watch?v=X6lGV5VE ... WW9PGylqjj )
Good luck om HDNes and congratulations!
Wow, I didn't know about HISMS and it is doing more or less the same thing as HDNes. Thank you for telling me this!
Now that I read the HISMS tutorial, I have 2 ideas that I think are not too difficult to implement:
1. The save screen function. I originally wanted to use this as the main method of extracting tiles from the game. But I think it would be too difficult to capture every single frame of the animations or special effects like that. So I programmed the emulator to generate the data automatically. However the drawback is that when an object is composed of many tiles, the emulator will not wait for the whole object to appear, so the object is split into many screen shots. I think I can add the save screen function so we can use either.
2. Direct screen mapping function. Similar to Auto generate, but instead of packing the tiles, the emulator generates two images per screen shot (one background, one sprite) and the tiles are placed in the image at the same location as the screen, so it will be easier to work with.
mkwong98 wrote:
Wow, I didn't know about HISMS and it is doing more or less the same thing as HDNes. Thank you for telling me this!
Now that I read the HISMS tutorial, I have 2 ideas that I think are not too difficult to implement:
1. The save screen function. I originally wanted to use this as the main method of extracting tiles from the game. But I think it would be too difficult to capture every single frame of the animations or special effects like that. So I programmed the emulator to generate the data automatically. However the drawback is that when an object is composed of many tiles, the emulator will not wait for the whole object to appear, so the object is split into many screen shots. I think I can add the save screen function so we can use either.
2. Direct screen mapping function. Similar to Auto generate, but instead of packing the tiles, the emulator generates two images per screen shot (one background, one sprite) and the tiles are placed in the image at the same location as the screen, so it will be easier to work with.
Yay! Hope to see these features on HDNes. I'm crazy to make some HD Nintendo hacks
Please download HiSMS later. You'll see the conversion process is really easy. You basically have to:
1) Take a screenshot
2) Change the screenshot graphics using an image editor
3) Overwrite the original screenshot with this redrawn image
3) Insert it back to the game with the click of a button
I'll watch this topic. Thanks and congratulations again!
Mkwong98 Hello, I would like to congratulate the initiative and say that I am extremely excited about his work. A long time ago I had the same idea but I have no knowledge to do it, I came to propose this in the forum kegafusion, even before they appear the hisms but was ridiculed and even booed by Some fanatics to the original, but these same I downgraded, I make use of filters for better image. Although you can not make it work on my pc (ATI HD core2quad + 59720 + Win7x64) I only get a black screen, but I was very happy to see the forum a screen nes "using high resolution sprites." wish I could help in some way if I can give my humble opinion, I would say not to re-invent the wheel ... we already have an excellent emulator nes well optimized and open source code, the "Nestopia" then it would not be appropriate to take advantage of what is already ready and integrate their ideas? is viable or not you want to have a project of its own, at least use it to streamline the consultation process programming. else if possible catalog versions file name to be made available for download. again good job!
28-4-2013:
1. Changed the generate data function so tiles which are partially outside the screen will not be recorded.
2. Fixed a bug with HD pack when a 16 pixel high sprite drop out of the screen (eg big Mario drops into a pit)
3. Added pause and unpause key.
4. Added a run one frame key.
5. Added a manual mode to data generation and added a manual generate data key.
6. When a screen shot is choosen, the emulator will generate HD pack data with tiles matching the actual screen shot. However currently this only works with background tiles as sprite tiles can be flipped and can overlap with other tiles.
7. Fixed a problem with nVidia graphics card. Thank you rainwarrior!
Thank you Macbee for showing me HiSMS.
leosmendes, thank you for your encouragement.
mkwong98 wrote:
28-4-2013:
1. Changed the generate data function so tiles which are partially outside the screen will not be recorded.
2. Fixed a bug with HD pack when a 16 pixel high sprite drop out of the screen (eg big Mario drops into a pit)
3. Added pause and unpause key.
4. Added a run one frame key.
5. Added a manual mode to data generation and added a manual generate data key.
6. When a screen shot is choosen, the emulator will generate HD pack data with tiles matching the actual screen shot. However currently this only works with background tiles as sprite tiles can be flipped and can overlap with other tiles.
7. Fixed a problem with nVidia graphics card. Thank you rainwarrior!
Thank you Macbee for showing me HiSMS.
leosmendes, thank you for your encouragement.
thanks , now work om my pc
A quick video of the emulator in action:
http://youtu.be/N57ApspYHVE I'm thinking of an easier way to handle palette swaps, so I'm not showing the fire flower or the star power up. Other than that, world 1-1 is done. And I just use a microphone to record the sound from the speaker, so please excuse the bad sound track.
That's pretty cool. Nice job!
16-5-2013:
Added a function to handle palette swaps if not using auto generate. If you have a sequence of tiles with the same palette and that sequence of tile also have the same palette swaps, then you can use this function to simplify the process.
First, make sure your HD renderings of the same palette are stored in the same image file. The same tile in different palettes must be placed in the same location relative to the first tile of that palette. Then add tile mapping for the first palette as usual. After that, click the 'Batch mapping' to open a dialog box. Select the image file of the first palette and select the first tile and the last tile of the sequence. Then select the new palette, the image file of the new palette and the location of the first tile within the image file. Click 'Add mappings' and the program will add mappings to the new palette for all the tiles between the first and the last, using the new location of the first tile as reference.
11-7-2013
1. Fix a save state crashing bug
2. Fix displaying 16 pixel high sprites
19-7-2013
Fixed sprites not showing during gameplay in Kirby's Adventure
Finished the HD pack for SMB! See the first page for a screenshot of the ending screen.
4-8-2013
1. Implemented showing leftmost 8 pixels of screen (bit 1 and 2 of PPU register $2001)
2. Implemented colour emphasis (not accurate)
Well, it works but man it's really slow. I am running an AMD FX-8150 eight-core overclocked to 4.40 GHz!
It seems like the higher the resolution is, the sloppier people are at drawing. How about making it 512x480, with the SNES color palette?
miker00lz wrote:
Well, it works but man it's really slow. I am running an AMD FX-8150 eight-core overclocked to 4.40 GHz!
If you has "Automatic" selected for "Generate data for graphics pack editor" then it will slow down everytime it encounters a new tile because it has to save the current screen to a png file. It was faster before when screen shots were saved in bmp format but that used up disk space far too quickly.
psycopathicteen wrote:
It seems like the higher the resolution is, the sloppier people are at drawing. How about making it 512x480, with the SNES color palette?
You can use 2x as the graphics pack scale, it does not need to match the display scale.
psycopathicteen wrote:
It seems like the higher the resolution is, the sloppier people are at drawing.
You're right that drawing 1080p sprites for Xbox 360, PlayStation 3, Wii U, and OUYA is a very different skill set from drawing low-definition sprites. One thing that helps is the use of vector tools such as Flash and then rasterizing the result.
Update 16-8-2013:
1. Fixed HD pack for 16 pixel high sprites.
2. Fixed DMC channel.
3. Implemented grayscale function.
mkwong98 wrote:
miker00lz wrote:
Well, it works but man it's really slow. I am running an AMD FX-8150 eight-core overclocked to 4.40 GHz!
If you has "Automatic" selected for "Generate data for graphics pack editor" then it will slow down everytime it encounters a new tile because it has to save the current screen to a png file. It was faster before when screen shots were saved in bmp format but that used up disk space far too quickly.
That explains it. I was playing Mega Man 2, it's all CHR-RAM. I wonder if you could maybe look into forking that workload into new threads. Keep a status flag to prevent it from doing it again on the next draw if it's still being processed from before. Maybe threading would break it though, I don't know how you're doing it exactly. Just a thought.
miker00lz wrote:
mkwong98 wrote:
miker00lz wrote:
Well, it works but man it's really slow. I am running an AMD FX-8150 eight-core overclocked to 4.40 GHz!
If you has "Automatic" selected for "Generate data for graphics pack editor" then it will slow down everytime it encounters a new tile because it has to save the current screen to a png file. It was faster before when screen shots were saved in bmp format but that used up disk space far too quickly.
That explains it. I was playing Mega Man 2, it's all CHR-RAM. I wonder if you could maybe look into forking that workload into new threads. Keep a status flag to prevent it from doing it again on the next draw if it's still being processed from before. Maybe threading would break it though, I don't know how you're doing it exactly. Just a thought.
Thank you for the idea, I'll try threading part of the screen shot function.
Update 27-8-2013:
1. Reduced the slow down of capturing the screen.
2. Added the audio pack function. Currently I know how to make one for SMB only. (It can also be used for adding cheat!)
Update 1-2-2014:
1. Added "additional conditions" to the audio pack.
2. Replace the readme file with a more in-depth version in pdf format.
3. Fixed save state for various mappers.
Update 10-3-2014:
1. Added mapper 7, 9 and 10.
2. Change the rendering from scanline based to tile based.
3. Fixed the initial tab page which was changed by mistake in the last update.
Update 5-4-2014:
1. Fixed a bug with overlapping sprites introduced in the last update.
2. Show the image file name instead of image id in the dropdown box and changed the size of some GUI components.
3. Added a button for removing an image from the graphics pack.
4. Added a button for optimizing the number of screen shots by removing redundant ones.
5. CHR RAM games will now use the tile pattern in addition with the colour palette when comparing. So now we can make graphics for CHR RAM games which modifies the tile patterns.
mkwong98 wrote:
CHR RAM games will now use the tile pattern in addition with the colour palette when comparing. So now we can make graphics for CHR RAM games which modifies the tile patterns.
What kind of "modifies the tile patterns" are you talking about? Are you talking about the sort of modification seen in Hatris, Qix, and 3D Block? I don't see how it'd work with a proportional font engine like that used in the STREEMERZ multicart and RHDE. (You'll see the latter once the 2014 compo entries become public). And for something like Videomation, I don't see how anything better than plain old hq2x is possible.
tepples wrote:
mkwong98 wrote:
CHR RAM games will now use the tile pattern in addition with the colour palette when comparing. So now we can make graphics for CHR RAM games which modifies the tile patterns.
What kind of "modifies the tile patterns" are you talking about? Are you talking about the sort of modification seen in Hatris, Qix, and 3D Block? I don't see how it'd work with a proportional font engine like that used in the STREEMERZ multicart and RHDE. (You'll see the latter once the 2014 compo entries become public). And for something like Videomation, I don't see how anything better than plain old hq2x is possible.
I'm talking about simple effects where an existing pattern is changed, but only slightly so that it is possible to account for all combinations. For example in 1943, the tiles on the right side of a ship use the same pattern as the left but flipped over. Another example is in Final Fantasy 3 where it shifts the pattern to make the water in the background appears to be flowing. Hope this answers your question.
This is a great project. I hope that artists become interested in creating HD remakes, like Marcelo Barbosa has done for Alex Kidd in Miracle World using HiSMS.
The sprite sheets for Super Mario Bros are fairly simple, so it's not an overwhelming project for an artist. Kung Fu and other early NES releases are the same way. And the characters of NES games tend to have very simple animation in general.
I'd love to take a closer look, but I can't get either HDNes or HiSMS working on my Mac using Wine. I believe that HiSMS doesn't work because it uses Direct3D 7 (rather than 8 or so). Not sure about HDNes.
Perhaps you could post a ZIP of graphics from an NES game, as ripped by HDNes, along with any remade graphics you've done?
I can see artists trying graphic packs for Super Mario Bros resembling New Super Mario Bros, Paper Mario or an animated style.
There is a lot of potential for 8-bit remakes. Consider:
Alex Kidd in Miracle World HD by MCBRemakes (Marcelo Barbosa)
by Pixeltao
by Jazaaboo.com
AlexDraws.Tumblr.com
Ducktales Remastered by WayForward
by Marobot
by Billysan291
Tygerbug wrote:
This is a great project. I hope that artists become interested in creating HD remakes, like Marcelo Barbosa has done for Alex Kidd in Miracle World using HiSMS.
The sprite sheets for Super Mario Bros are fairly simple, so it's not an overwhelming project for an artist. Kung Fu and other early NES releases are the same way. And the characters of NES games tend to have very simple animation in general.
I'd love to take a closer look, but I can't get either HDNes or HiSMS working on my Mac using Wine. I believe that HiSMS doesn't work because it uses Direct3D 7 (rather than 8 or so). Not sure about HDNes.
Perhaps you could post a ZIP of graphics from an NES game, as ripped by HDNes, along with any remade graphics you've done?
I can see artists trying graphic packs for Super Mario Bros resembling New Super Mario Bros, Paper Mario or an animated style.
There is a lot of potential for 8-bit remakes. Consider:
Thanks for mentioning my work, Tygerbug!
Last time I tried HDNes it was very complicated to me - but I'm still very interested in making a NES -> HD hack someday.
Your work on Alex Kidd is gorgeous, Marcelo, as is all the other stuff at your blog.
I'd love to see you tackle other games from an art standpoint. Perhaps you could ignore HDNes for now and just work from Spriters Resource sprite sheets, enlarged to 4x. Once the art exists - that's the hard part - mkwong or someone else could implement it.
I've been considering doing some sprite work in Super Mario Bros X format if I can ever find the time. That does allow for 2X detail but that's about it.
An HD remake needs a good artist. I'd be very interested in seeing what people could come up with for SMB1. A New Super Mario Bros style would be fun -
But really I'd love a classic 90s animated style:
Paper Mario would work too - and use existing sprites for the most part.
I wonder which Master System games would be worth remaking. I did have a Game Gear but I'm not familiar with the SMS for the most part. I can think of plenty of NES games though!
Here's someone's SMS list:
http://www.retro-sanctuary.com/TOP%2010 ... e%205.htmlhttp://www.retro-sanctuary.com/TOP%2010 ... e%204.htmlhttp://www.retro-sanctuary.com/TOP%2010 ... e%203.htmlhttp://www.retro-sanctuary.com/TOP%2010 ... e%202.htmlhttp://www.retro-sanctuary.com/TOP%2010 ... e%201.html
Tygerbug wrote:
Your work on Alex Kidd is gorgeous, Marcelo, as is all the other stuff at your blog.
Thank you very much! The majority of my blog entries (NES remakes/demakes) are only possible due to thefox's "Nes Image Converter" program.
Tygerbug wrote:
I'd love to see you tackle other games from an art standpoint. Perhaps you could ignore HDNes for now and just work from Spriters Resource sprite sheets, enlarged to 4x. Once the art exists - that's the hard part - mkwong or someone else could implement it.
I also believe that it would be nice to use HD sprites on a brand new game (optimized for modern systems).
I'd like to reuse my Alex Kidd sprites on an improved port (for Android or Windows). But it demands time and hard work - and since I don't have their rights / licenses it would be sort of useless.
Tygerbug wrote:
I've been considering doing some sprite work in Super Mario Bros X format if I can ever find the time. That does allow for 2X detail but that's about it.
Nice! If you create these graphics please post them here.
Tygerbug wrote:
An HD remake needs a good artist. I'd be very interested in seeing what people could come up with for SMB1. A New Super Mario Bros style would be fun -
But really I'd love a classic 90s animated style:
I also would choose the 80s/early 90s cartoon style. I personally don't like the CG art used since Super Mario 64 to present day.
JinnDEvil created awesome SMB1 pixel art sometime ago. I guess you'll like it:
http://jinndevil.tumblr.com/post/542869 ... io-bros-onTygerbug wrote:
I wonder which Master System games would be worth remaking. I did have a Game Gear but I'm not familiar with the SMS for the most part. I can think of plenty of NES games though!
I'd like to change small, simple games like Teddy Boy and exclusive (for SMS and GG) platformers like Land of Illusion and Deep Duck Trouble. By the way it's possible to change Game Gear games to High Resolution with HiSMS.
Nice. I know that Castle of Illusion for Genesis/Mega Drive was remade in HD / 3D recently at least.
Disney games set the bar pretty high in terms of what the characters absolutely have to look like ...
http://www.spriters-resource.com/game_g ... dimecaper/
Thanks for sharing! I'm particularly impressed by the first Ninja Gaiden image. If anyone is interested, I can share my works on the two games. But I don't want to post them here because they are not related to making an emulator.
mkwong98 wrote:
Thanks for sharing! I'm particularly impressed by the first Ninja Gaiden image. If anyone is interested, I can share my works on the two games. But I don't want to post them here because they are not related to making an emulator.
Please share your works. Maybe we should create another topic (to talk specifically about HD graphic hacks).
Please do share - here or elsewhere. Since I can't run HDNes on my Mac, I'd love to see what format it rips games in, and what that image data ends up looking like - to see what it would be like to work with that material. How about the Super Mario Bros rip at least?
LinkofAwesome's 2x designs:
How hard would it be to do either of these?
- Watch bytes in RAM to determine a character's state, so that Mario uses different frames in a walk or run.
- Watch bytes in RAM and allow expansion of looping sequences, so that a fundamentally nonsensical 3-frame walk cycle repeating the same side over and over can be expanded further to a 6-frame walk: 3 frames for the left foot and 3 frames for the right.
Here's a nice Mario from Yoshi's Cookie on the Gamecube.
http://www.spriters-resource.com/fullview/12228/And Yoshi, plus some enemies and Toad:
http://www.spriters-resource.com/fullview/12230/Paper Mario: The Thousand Year Door:
http://www.spriters-resource.com/gamecube/pmttyd/3D models from Mario Party 8:
http://www.models-resource.com/wii/marioparty8/Golf:
http://www.spriters-resource.com/game_b ... eet/12301/Picross:
http://www.spriters-resource.com/fullview/60524/Pinball:
http://www.spriters-resource.com/game_b ... heet/8121/It's nice that people are ripping the actual 3D models from Wii, Gamecube and other systems, and animating with them. An 8-bit remake could look very slick with renders like that! Which could also be taken from the newer-gen games themselves. I spotted models from Bubble Bobble, Adventure Island and so on - since those have been remade.
I did some quick tests trying to rig Birdo and Waluigi in Poser. Not my strong suit!
Yeah, might be best to move a discussion of graphics elsewhere.
http://jinndevil.tumblr.com/post/542869 ... io-bros-on
tepples wrote:
How hard would it be to do either of these?
- Watch bytes in RAM to determine a character's state, so that Mario uses different frames in a walk or run.
- Watch bytes in RAM and allow expansion of looping sequences, so that a fundamentally nonsensical 3-frame walk cycle repeating the same side over and over can be expanded further to a 6-frame walk: 3 frames for the left foot and 3 frames for the right.
It won't be too difficult to do "a" and I think I may do that after I improve the speed of the emulator. Currently it slows down if there are many different tiles on the screen. "b" will be much harder to do because a tile in one frame isn't directly linked to the one in the next frame. Besides that, defining animation frames is not a simple task and so the GUI will need a lot of work too.
Watch bytes that control animation cycling, and whenever a certain byte (representing frame number) decreases, switch a certain tile range to a different bank of high definition tiles. Thus you'd end up with one bank for "taking a step with the left foot" and another for "taking a step with the right foot".
[Sorry - more graphics discussion - I should start a different thread for this.]
A couple people are interested in having a look at the sprites for Super Mario Bros, as HDNes ripped them.
Posing 3D models correctly to match the NES sprite sheets of certain games would be interesting. There's plenty of material available - The 3D character models from many video games have been ripped, and other 3D models created by artists. I'm on Mac, so my options are often limited, and I'm not a 3D animator but I do know Poser very well, at least. I did some quick tests last night rigging up Waluigi and Birdo - sort of a mess, but just quick tests anyway.
A lot of videogame models are available for XNALara, aka XNA Posing Studio, and they come fully rigged. I tried out an attempted Mac equivalent called GLLara, but it crashed constantly and was difficult to pose with. Even so, I was able to do a little posing with Ryu Hasabusa (DOA5/Ninja Gaiden), The Teenage Mutant Ninja Turtles, various Mario characters, and so on.
At times like this it's a pain to be on a Mac, since so much software (especially indie software) doesn't work on it, or work correctly. Oh well.
I've just drawn some new sprites for an NES game - I'll ink and share those when I can.
There's something called MonoGame that may allow XNAWhatever to be ported.
Not sure -- they haven't built it for Mac for awhile.
I think 3D graphics would be the way to go for Ninja Gaiden, Batman, Sunsoft's unreleased Superman (Sunman) ...
Sednaiur has done some large-scale (2X, 4X) characters for the Super Mario Bros games, in All Stars style, with lots of expanded graphics and variations.
http://knuckles96.prophpbb.com/topic13446.htmlhttp://www.supermariobrosx.org/forums/v ... 1&start=70
Tygerbug wrote:
Excellent news, thanks for sharing!
Isn't that great? This should make colorizing Game Boy games relatively straightforward.
Shonumi writes:
Quote:
Glad you like the idea behind GB Enhanced! You can thank AnyOldName3 for suggesting it; the concept intrigued me. I actually stumbled upon both projects (HiSMS, HDNes) a few months back. Looks like I'm not the only one who had that idea. Fwiw, there was a proof-of-concept GB emulator that did allow HD tile replacement, but it was incomplete (and I don't think it handled colorizing DMG games). I'm not exact the first when it comes to the GB, but I guess I've gone the farthest.
GB Enhanced only handles 1:1 tile replacements, but support for arbitrary scales (2:1, 3:1, 4:1, etc) is already implemented in a new branch. There are still some finishing touches that need to be applied, but it works. GBC tile replacement isn't supported yet, but that's coming soon. A shame I don't have screenshots on hand to show you any progress.
Mkwong98, thank you for the HDNes Super Mario Bros sprite information. The way you've organized the HD version is very straightforward and will make replacing the graphics simple even though I can't run the program on my Mac.
Let me know if you have/can do any other organized sprite versions, like SMB2 and Mr. Gimmick and so on (Mega Man, Rescue Rangers).
I did some sketches of the SMB and SMB2 Mario Brothers. SMB2 is much easier, despite the two-frame walk cycle - they look like the current Mario Bros. The three-frame walk cycle is pretty confusing in SMB1, and his design is different enough from the current Mario that it's going to take some thought.
Jinn.art.br did a really nice "darker" take on SMB1, so I've asked him to have a look at this, as that's probably the right way to go.
For SMB1, use the SMB3 design and expand the walk to six frames.
That's pretty much what All Stars did, although I think it'd still be possible to get closer to the SMB1 sprites while still making it "look like Mario."
Jinn had a very interesting idea on how to approach it - ignoring the other games and going for a different style. I've asked him to take a look at things.
http://i.imgur.com/dWO7anJ.gifhttp://www.pixeljoint.com/files/icons/full/smbpj.gifhttp://jinndevil.tumblr.com/post/542869 ... io-bros-on
That looks nice!
Comparisons to Braid's art style come to mind, which may or may not be welcome...
(and Braid's status as an homage to SMB is known)
Looking nice. Now all someone needs to do is draw Cloud Strife from Final Fantasy VII with George W. Bush's head. You can't unsee it.
it's a really good emulator.
24-5-2014
1. Fixed a bug when removing redundant screen shots used by the graphics pack editor.
2. Compiled the emulator with SSE.
3. Reduced the amount of rendering by keeping graphics data from one frame to the next. Large speed improvement when using 4x graphics pack in games with many unique tiles appearing at the same time on the screen but do not vary a lot between frames. For example the title screen of Dragonball Z.
I haven't tried HDNes yet, since I'm on a Mac right now, but...
Does this emu have flicker when playing NES games with their original graphics, like all other emulators?
If so, would it be possible to add a mode in which the emulator automatically uses the game's original tile set *as if* it were an HD graphics pack, so as to eliminate flicker?
I'm not really interested in HD graphics, but to be able to play NES games with their original graphics and no flicker would be quite revolutionary.
Trevor_NT wrote:
I'm not really interested in HD graphics, but to be able to play NES games with their original graphics and no flicker would be quite revolutionary.
Not that revolutionary. Nestopia, for example, has had this feature for ages: Machine => Options => No Sprite Limit. Nestopia's implementation is slightly questionable, though, because the setting also affects the sprite overflow flag which could cause some games to break.
I think FCEUX has a "disable 8 sprites limit" switch, which eliminates flicker due to overdraw limit. It might be one of the things that old vs. new PPU changes. It won't eliminate intentional flicker where a sprite isn't drawn at all in one or more frames, like injured Mario in SMB1 or the smoke and explosions in Thwaite; for that, you need a motion blur filter as seen in GBA emulators.
thefox wrote:
Trevor_NT wrote:
I'm not really interested in HD graphics, but to be able to play NES games with their original graphics and no flicker would be quite revolutionary.
Not that revolutionary. Nestopia, for example, has had this feature for ages: Machine => Options => No Sprite Limit. Nestopia's implementation is slightly questionable, though, because the setting also affects the sprite overflow flag which could cause some games to break.
I know some emulators have this option, but... maybe I'm being silly, but does it actually work?
I'm talking, off the top of my head, about games like Konami World 2, Super Dodge Ball (
https://www.youtube.com/watch?v=ARmZjy2HF_4) and Guerilla War/Guevara, which are flickerfests I never could solve. Also, there is this effect with the tiles in the background, in which they blink distractingly when scrolling into the screen (You can see it here, right side of the screen:
http://youtu.be/8BOv7GuhdB0 . Also, notice the UI permanently glitching on the lower left corner.)
Anyway, if HDNes could have a mode like I described and it brought any gains in the sense of more stability to the graphics, that would be awesome.
The effect at the right side of SMB3 is a consequence of the fact that the NES has enough video memory for two screens. Because SMB3 levels are two screens tall, it stacks the two screens on top of each other. This means a 16-pixel-wide color area straddles the scrolling seam between the left and right sides of the screen. And often this color area will end up discolored because making it correct for one side will make it incorrect for the other side.
Super Dodgeball looks like it flickers because there are too many sprites to display in a frame, and then it also might flickers due to the sprite scanline limit. Eliminating the scanline limit would reduce flicker only slightly. You'd need a specific emulator hack/feature on a per game basis that would allow the game to draw and display all characters every frame. It could be done.
I'm not sure if Guerrilla War is the same deal but it's likely.
The SMB3 glitches, the palette issues could be hidden by not drawing that edge of the screen. Some emulators allow this by an option menu. The glitch in the bottom status bar is related to IRQ and PPU timing. This can be fixed in emulation by changing the way the PPU behaves.
The flickering glitch can't be corrected by graphics pack function. This is because the function replaces graphics, so it only works on objects which are visible in the original. On the other hand, the palette glitch can be corrected by defining a default replacement for the tile regardless of the actual palette being used.
MottZilla wrote:
Super Dodgeball looks like it flickers because there are too many sprites to display in a frame, and then it also might flickers due to the sprite scanline limit. Eliminating the scanline limit would reduce flicker only slightly. You'd need a specific emulator hack/feature on a per game basis that would allow the game to draw and display all characters every frame. It could be done.
I'm not sure if Guerrilla War is the same deal but it's likely.
The SMB3 glitches, the palette issues could be hidden by not drawing that edge of the screen. Some emulators allow this by an option menu. The glitch in the bottom status bar is related to IRQ and PPU timing. This can be fixed in emulation by changing the way the PPU behaves.
That's why I gave that suggestion. I understand that HDNes, by overlaying the original rendering system with new graphics, also bypasses all these glitches.
If there was a mode in which the original graphics were automatically rendered in this new system, as if they were a graphics pack, like the one created for Super Mario Bros... see what I mean?
mkwong98 wrote:
The flickering glitch can't be corrected by graphics pack function. This is because the function replaces graphics, so it only works on objects which are visible in the original. On the other hand, the palette glitch can be corrected by defining a default replacement for the tile regardless of the actual palette being used.
Wait... you mean that Super Dodge Ball with an HD graphics pack would glitch in the same way?
Edit: Let's be clear. If I create from scratch an HD graphics pack for a game like Super Dodge Ball, would these new graphics also glitch?
If not, wouldn't it be possible to create a function in the emu that extracts the original graphics, the tiles and such, organizes and allocate them on the fly in RAM, and displays them as if they were a graphics pack, to bypass these glitches?
Again, sorry for talking theoretically, I'm travelling and can't test HDNes here.
It would have the same flickering because the game exceeds the amount of sprites that can exist on the screen at one time. You can place 64 sprites anywhere on the screen you want each frame. When a game has too many objects to drawn than will fit into this list, some don't get drawn. So it will cycle through these objects to draw them in a way where they all get a turn to be seen.
This means the game needs to have its programming changed so that when it goes to draw objects (building the Sprite RAM table) that it builds an even bigger table to send to the emulator's modified PPU which can draw all the objects. That's the basic idea.
The flickering isn't a "glitch". The flicker is the result of the hardware limitation of the NES PPU. It could be improved in emulation with per-game attention.
Yes, it is beyond the scope of the graphics pack function to eliminate flickering as MottZilla posted.
How does motion blur filter on GBA emulator work? Do you think it would help if I paint the previous frame with 50% transparency on top of the current frame?
Oh, I get it now. I thought a rendering system that made the HD packs possible would be some sort of overlay that necessarily had the side effect of eliminating the glitches, but I was obviously wrong.
Just saw this video, and at 00:00:16, when Link gets close to the enemy and attacks, the sprite flickers.
http://youtu.be/DknjUcQ7jawBut, anyway... seeing this game with those improved graphics is quite a revelation. HDNes is a very cool project, congrats.
Trevor_NT wrote:
Oh, I get it now. I thought a rendering system that made the HD packs possible would be some sort of overlay that necessarily had the side effect of eliminating the glitches, but I was obviously wrong.
Just saw this video, and at 00:00:16, when Link gets close to the enemy and attacks, the sprite flickers.
http://youtu.be/DknjUcQ7jawBut, anyway... seeing this game with those improved graphics is quite a revelation. HDNes is a very cool project, congrats.
Thanks. I'm really impressed by the video too. And I'm very surprised that he actually works out how to replace sound tracks. It requires in depth knowledge of the games.
mkwong98 wrote:
And I'm very surprised that he actually works out how to replace sound tracks. It requires in depth knowledge of the games.
Replacing music is the same skill set as ripping NSFs. In fact, if you have an NSF, you already know how where to look in the code to remove the game's own music player and replace it with writes to the "play track" register.
tepples wrote:
Replacing music is the same skill set as ripping NSFs. In fact, if you have an NSF, you already know how where to look in the code to remove the game's own music player and replace it with writes to the "play track" register.
Then I need to learn how to read NSF files.
I enjoyed your HD sprite pack for Kung Fu. Wouldn't mind seeing a video of that!
I sketched out some HD sprites for Super Mario Bros 3 ages ago, but haven't finished work on them yet. Been overwhelmed with things.
I'll make a video and post it on youtube soon. For the time being, have a look at my personal long term project:
http://youtu.be/uC73qM8YPPEThis is a big game and I'm adding some functions to HDNes to make it easier to work with.
I uploaded a video of a quick run of Kung Fu:
http://youtu.be/yySSNxkQ4Q8
6-7-2014
1. Fixed a few bug that may cause Batch mapping dialog to crash.
2. Improved speed by copying a pointer instead of copying a large object.
3. Added the ability to select multiple tiles using shift key and ctrl key.
4. Added the ability to specify the brightness when displaying a replacement tile.
5. Added the ability to automatically detect and add mappings with a lowered brightness to darker palettes.
6. Added the ability to customize the palette manually or by importing the colours from a file.
7. Added a panel next to the screen shot for displaying the selected tile enlarged.
Thanks for the update! Great to see Kung Fu --
A rough attempt at Mario in HDNes using some of João Victor G. Costa's sprites (by Alex Douglas).
https://www.dropbox.com/s/wqql5xqr6lw5x9d/Mario.zipAnd some Super Mario Bros 2 background art, and other stuff, from my comic.
https://www.dropbox.com/s/qxfjksaqouxbw ... mario2.zip
João Victor G. Costa writes:
I had some problems figuring out the best way to approach it, since the mario sprite uses just half of the body and flips it to make it whole. Also, my sprite is a bit taller than 2x the original...
https://www.dropbox.com/s/xwi0bqe02c8jwhm/Clip0001b.pngIt also lags a lot on my computer.. The music becomes awful slow ;/
Do you think there's a way to make a full mapping of the sprites and tiles with the flipped parts?
A full Mario body instead of a half!
Tygerbug wrote:
João Victor G. Costa writes:
I had some problems figuring out the best way to approach it, since the mario sprite uses just half of the body and flips it to make it whole. Also, my sprite is a bit taller than 2x the original...
https://www.dropbox.com/s/nnnyamqdap1huz4/Clip0001b.pngIt also lags a lot on my computer.. The music becomes awful slow ;/
Do you think there's a way to make a full mapping of the sprites and tiles with the flipped parts?
A full Mario body instead of a half!
To do that, the emulator must allow the user to use RAM values and tile orientation to choose a replacement tile. In this case, we need to check which direction is Mario facing as well as whether the tiles are flipped or not. If he is facing right then the normal tiles is his back side and the flipped tiles is his front side. If he is facing left then the normal tiles is his front side and the flipped files is his back side.
This is a powerful feature and tepples suggested it too. In fact that problem is also one of the biggest difficulty I found so far when making HD pack. It is that when some tiles are used in 2 or more different situations with the same palette, it greatly restricts what we can put into those shared tiles. But with this feature, the user can identify the different situations and provide different replacement tiles. But it will take a long time to implement and I'm not ready to do it yet.
Hi there! I am Alex Douglas, as tygerbug mentioned above, I have been using João Victor G. Costa's artwork alongside HDNes and provided the previous screenshots.
I have made some more progress, so here are some screenshots to showcase exactly what this emulator can do. Enjoy!
As a side note: Although not pictured here, the reskinned fireball graphics apply as well to the Fire Bars in Bowser's castle, of course.
João Victor G. Costa sent me some stuff and I've added it here --
https://www.dropbox.com/sh/j6xpmtd2j883 ... YLy9fDxE7a
Hi guys! GreenGuy here. I'm glad you like my projects (Zelda 2 & Metroid revamps). Figuring out how the music worked was a bit tricky at first but now I'm a pro. If anyone needs help with this program just let me know. I'll be happy to help you out as best as I can.
@mkWong: newest build has serious trouble loading savestates for me. 99% of the time crashes.
asshat818 wrote:
@mkWong: newest build has serious trouble loading savestates for me. 99% of the time crashes.
Thanks for telling me, I'll take a look at it.
GGuy was able to get a video of my progress on HDMario! Although it seems like the option "use as default tile regardless of pallette" got unchecked for some things like coins and boxes. A big thanks to GGuy for recording this for me
http://youtu.be/UcTokxwSyEM
Thanks to GGuy! And it's good to have you here. I look forward to seeing more from you.
These are all very cool:
http://www.youtube.com/watch?v=eV-5vujk ... tA5LMjYnPA Joao's Super Mario Bros. backgrounds in particular are looking great so far.
Nice work everyone!
20-7-2014
1. Fixed a load state bug by pushing load state and save state to the end of current frame.
I had an idea, though I could completely understand if it would not be possible.
Basically have HDNes detect the background color and effectively chroma key (green screen) it out, to be replaced with a much higher quality background image. Though with some colors, such as a black background, that appear on screen in places other than the background, I could see this as being unfeasible, thoughts mkwong?
It is possible. Instead of filling the screen with the background colour, I can paint the background image onto the screen before rendering other layers. Some games keep the background black and use transparent pixels in place of black, in this case the user can provide a replacement tile with solid black instead. However if the games also change the background colour and combine with transparent pixels to produce special effects (for example lightning), then the replacement tile will not work.
The only other big problem I can think of is how well the emulator can run with this feature. Uploading a large texture (1024 * 960 for 4x) to the graphic card is slow and uses a lot of memory. Besides that, the emulator needs to update the sprite and bg texture and vertices every frame and that is pretty slow too. I'm not sure how doing both will affect the speed.
The large texture for the backdrop would need to be changed rarely, only when the player enters a new map or when the emulator has to reload everything anyway (such as Alt-tab in and out causing loss of the DirectX surfaces). And a backdrop texture would often be blurry enough to be amenable to S3 texture compression. I'm just concerned about games that don't use color 0 for the background, such as Concentration Room in-game (whose color 0 is white but whose actual background is brown).
Was scripting support ever considered? That could provide a nice way to do music upgrades as well.
By scripting support I mean that a script file could be bundled with the HD pack of a game that could perform some operations based on some trigger conditions (execution breakpoints would be sufficient at least for some features like music and sfx triggering). Hard part would be of course figuring out what sort of API would be flexible enough. But if a scripting system was good enough, it could maybe used to smooth out some of the parts that can't be handled automatically.
Usually it's a pair like LDA #$value, JSR $address. Quite cool the idea, someone could trap sound fx and music "codes".
Trapping code is a good idea. Thanks.
My to-do list is like this(not necessarily in order):
1. Create HD pack for one action CHR ROM game. (Castlevania)
2. Create HD pack for one RPG CHR ROM game. (Dragonball Z)
3. Create HD pack for one action CHR RAM game. (1943)
4. Create HD pack for one RPG CHR RAM game. (Final Fantasy)
5. Add more mappers. (a few Konami mappers and MMC5)
I want the internal working of the emulator to mature before adding scripting support. So I won't consider it until I have MMC5 working.
Here's more pixel art by Joao Victor G. Costa.
https://www.youtube.com/user/JinnDemonEvil/videosYou can support him on Patreon --
http://www.patreon.com/jinn
mkwong98 wrote:
My to-do list is like this(not necessarily in order):
1. Create HD pack for one action CHR ROM game. (Castlevania)
Castlevania (the first one) is CHR-RAM, the UNROM mapper.
Thanks for spoting that. In that case I think I'll do Astyanax instead.
24-8-2014
1. Added an option to show all tiles on the screen instead.
2. When "All" is selected in the screen shot dropdown box, shows screen shot name for tiles which have no replacement
BTW I uploaded the source code to GitHub for anyone interested.
Great new additions mkwong. I'm extremely happy to see the source has been released.
Tonight I started putting together a spreadsheet listing the compatibility of games thanks to the
NesCartDB.
I should have it done by tomorrow maybe. US carts only right now. Green = The game works. Red = It's a CHR RAM game or other issues and there will be problems. And finally Yellow means that there is an unsupported mapper and it will not load.Check it out here.
HDNes Compatibility Listedit: I updated the list today. Problem games are now marked as red, CHR RAM are now blue, yellow is still unsupported mapper and green of course means it should work without any problems.
You may as well just set aside all of Nintendo's AxROM, BNROM, and UxROM games right now, rather than bothering to test them—they all use CHR-RAM.
SGROM, SMROM, SNROM, SOROM, SUROM, SXROM, TGROM, and TNROM too. (
http://wiki.nesdev.com/w/index.php/SxROM &
http://wiki.nesdev.com/w/index.php/TxROM )
Alrighty, thanks for the suggestion.
I'm pretty much finished with it now. Just a few more Japanese carts left to check. Hopefully this list will help anyone that wants to make a pack.
Attachment:
QQ截图20140826153810.jpg [ 120.16 KiB | Viewed 2745 times ]
hi, author!
the tiles which color are red correspond to the same one,
how can i make the tiles correspond to the different?
sorry i dont know much about the technic.
my problem may be naive...
GGuy wrote:
Alrighty, thanks for the suggestion.
I'm pretty much finished with it now. Just a few more Japanese carts left to check. Hopefully this list will help anyone that wants to make a pack.
Thank you! It will be useful for me too.
LittleMike wrote:
hi, author!
the tiles which color are red correspond to the same one,
how can i make the tiles correspond to the different?
sorry i dont know much about the technic.
my problem may be naive...
Sorry, the emulator can't do that yet. BTW do you speak Chinese? You can ask questions in Chinese if you want. If you ask in Chinese here, I'll translate it to English for other readers. Or you can ask in the Chinese board and notify me about it, then I'll answer it there.
It would be interesting to see Yie Ar Kung Fu in an HD Street Fighter style.
Hey, I am the author of GB Enhanced, a Game Boy emulator that has the same ability as HDNES more or less (just without a GUI at the moment...)
I have been watching your work and just wanted to stop and say hello. I am really excited to see the source code online on GitHub. I would like to see your approach to handling certain situations, so I will examine the code some time soon.
I am also working on a white-paper detailing a general "theory" about "HD Graphics" in 2D systems like the NES, Genesis, Game Boy, etc, by replacing the game's graphics (the tiles). I am still working on it, but I would like to have the input from another person developing a similar emulator. I see LittleMike asked about replacing tiles that are technically the same on a given screen. I can assure you, this too is an issue I have encountered, and I believe it is an inherent issue that emulators like ours must deal with. How would you solve the problem LittleMike described? Do you have any ideas (even untested ones) that might work? I do not know much about the NES (I know a lot about the GB/GBC/GBA systems though) so I would like to hear what you would do. I have my own preliminary idea on how to solve LittleMike's problem, but it still needs to be refined.
Keep up the good work
You're doing great work, Shonumi.
Shonumi wrote:
Hey, I am the author of GB Enhanced, a Game Boy emulator that has the same ability as HDNES more or less (just without a GUI at the moment...)
I have been watching your work and just wanted to stop and say hello. I am really excited to see the source code online on GitHub. I would like to see your approach to handling certain situations, so I will examine the code some time soon.
I am also working on a white-paper detailing a general "theory" about "HD Graphics" in 2D systems like the NES, Genesis, Game Boy, etc, by replacing the game's graphics (the tiles). I am still working on it, but I would like to have the input from another person developing a similar emulator. I see LittleMike asked about replacing tiles that are technically the same on a given screen. I can assure you, this too is an issue I have encountered, and I believe it is an inherent issue that emulators like ours must deal with. How would you solve the problem LittleMike described? Do you have any ideas (even untested ones) that might work? I do not know much about the NES (I know a lot about the GB/GBC/GBA systems though) so I would like to hear what you would do. I have my own preliminary idea on how to solve LittleMike's problem, but it still needs to be refined.
Keep up the good work
If the tiles are stationary then I can use the tile location as well as the tile pattern and color to identify the tile, or I can let the user add a HD background image based on some value in the RAM. Otherwise it may be possible to use tile location and the scroll offset values from RAM to identify every single background tile on the screen, but that will be much more complicated and may require a script engine.
I think a hash table based on tile pattern would probably be the most productive way to start handling CHR RAM based systems like Master System, Game Boy family, and 25% of the FC/NES library. (I just checked NesCartDB, and 356 out of the 1397 known distinct games contain CHR RAM.)
@tepples - This is the conclusion I have come to, and it pretty much forms the basis for my general theory on being able to replace 2D graphics for any tile-based console or handheld. Adequate hashing (in theory anyway) should provide every single tile for a system. So long as you can generate a unique hash for every tile that the emulator wants to draw, it should be possible to replace that. Obviously there are unique difficulties to adapt to (like when colors "fade in" or "fade out" which requires some careful hashing of tile and palette data) but that is the gist of it.
One of the bigger problems I have faced using this method is that some tiles are usually reserved for the background but appear in multiple places and serve multiple functions. The all-white tiles that make up the sky in Super Mario Land are a great example. These can be hashed, dumped, and edited, but this has the effect of replacing
every all-white tile in the game, unfortunately, because the hash is the same. Not only is the "sky" replaced, but everywhere that has a white background (which is most of the game). To this end, I have disabled dumping tiles that are solid colors by default. Obviously this issue is reduced when moving to the GBC and the GBA, since the tiles become more unique and varied.
@mkwong98 - Someone mentioned to me that using the location of a tile to be included as part of a hash (or an ID if you will) would be a nice solution for something like LittleMike's problem. I have no idea about how viable that is on the NES, but I have expressed my doubts, at least as it concerns the Game Boy. I guess what you NES folks call the Nametable is most comparable to the GB family's Background Maps. I believe you are correct when it comes to replacing stationary images, since this is very simple. The Background Map is essentially static data at that point. When the screen moves in scrolling games, however, the BG Map is rewritten (not all at once, usually) because new areas need to be shown. Is this how NES games with CHR RAM work as well?
If that is the case, it makes replacing tiles like LittleMike pointed out troublesome because the tile's location in the Nametable/Background Map continually changes. It is definitely possible to do it for non-stationary backgrounds, I just can't imagine it being very fun to code
Sorry if you consider this off-topic talk, I just find this to be a fascinating area of emulation, one we have yet to perfect, and one that we have yet to fully exploit.
For CHR RAM games, besides the tile pattern, HDNes also remembers the address of the last PRG ROM read when writing the tile to CHR RAM. The emulator assumes the game does not read from other PRG ROM addresses when transfering tiles from PRG ROM to CHR RAM. Then this address can be used as part of the tile identification as well. I'm not sure how well this will work, I haven't make a HD pack for a CHR RAM game yet.
Hey Shonumi. I believe it was me that suggested the ID thing. I posted it on google code. Anyways I have an idea about the all solid colors thing. It's not ideal but what I've been doing is editing the CHR data in the rom and making the solid tiles unique. Of course having people patch a rom is kind of a pain so perhaps the way to resolve this temporarily is to implement ips patching. Then whoever makes an HD pack can simple add a IPS file to the directory and resolve any duplicate hash problems because they would have edited the solid colors in the CHR.
Mkwong, I've experimented with Metroid a CHR-RAM game and the only issues I was running into was unsupported mappers. It's been awhile since I did anything with that though so I will need to retest that.
edit: Well that's strange. Starting a CHR-RAM game with graphic pack data now crashes the emulator.
@GGuy - Oh, so that was you
Actually what you suggested just now is very similar to the WIP idea I have. Essentially I guess you would call it a "Virtual Tile Map" ("Virtual Nametable" in NES-speak?) in that the emulator reads the Map data as usual, but the user can forcibly override certain entries with data of their own. It's basically in-game patching, but without touching the ROM itself. I am trying to figure out a reliable implementation; the emulator needs to determine when it is time to override the Map provided by the ROM, and when to leave it alone.
mkwong98's comments about detecting transfer addresses into CHR-RAM (or really just VRAM in GB-speak) is something I will consider in solving the so-called "solid-color" problem. There's something there, I know it. I'm too busy getting my GBA emulator off the ground to mess with anything GB/GBC related though.
I will give HDNES a try later this weekend. It is Windows only, correct? I should be able to run it in WINE though.
Shonumi wrote:
I guess what you NES folks call the Nametable is most comparable to the GB family's Background Maps. I believe you are correct when it comes to replacing stationary images, since this is very simple. The Background Map is essentially static data at that point. When the screen moves in scrolling games, however, the BG Map is rewritten (not all at once, usually) because new areas need to be shown. Is this how NES games with CHR RAM work as well?
Yes. Both games with CHR ROM and games with CHR RAM work this way. Load Contra into an emulator with a nametable viewer and see updates at the scroll seam not unlike
those of Super Mario Bros. Heck, SMB1 itself runs on at least one board with CHR RAM, namely the Nintendo World Championships (NES-EVENT) board.
GGuy wrote:
Anyways I have an idea about the all solid colors thing. It's not ideal but what I've been doing is editing the CHR data in the rom and making the solid tiles unique.
That might work for CHR ROM, not so much for CHR RAM because a solid tile often compresses to one or two bytes. And for a couple compression methods I've been meaning to implement, not even "last data fetch from ROM" would help because they'd end up seeing a constant table used by the decompression code. Your real-time IPS would end up having to rewrite all the CHR loading code to write a unique ID instead of tile data.
GGuy wrote:
edit: Well that's strange. Starting a CHR-RAM game with graphic pack data now crashes the emulator.
Ok I fixed the bug when reading HD pack of CHR-RAM games. Thanks for telling me.
Shonumi wrote:
I will give HDNES a try later this weekend. It is Windows only, correct? I should be able to run it in WINE though.
Yes, it is windows only. The platform specific code is for file and directory handling and I can't figure out how to do it cross platform.
tepples wrote:
That might work for CHR ROM, not so much for CHR RAM because a solid tile often compresses to one or two bytes. And for a couple compression methods I've been meaning to implement, not even "last data fetch from ROM" would help because they'd end up seeing a constant table used by the decompression code. Your real-time IPS would end up having to rewrite all the CHR loading code to write a unique ID instead of tile data.
If I can define a list of address ranges to be included/excluded when monitoring the last data fetch then it might work. Script engine will be the most robust approach. I have problems keeping it running at 60 fps as it is so I'm not too keen on adding more to it yet.
Shonumi, which library do you use for graphics? I'm using GLSL, but the uploading the tiles as a texture onto the graphics card is not a fast process and doing it every frame makes the emulator very slow on older machines.
GGuy, what program did you use to record the youtube clips? I can't a recording with good frame rate and no slow down.
mkwong98 wrote:
GGuy, what program did you use to record the youtube clips? I can't a recording with good frame rate and no slow down.
I use OBS.
https://obsproject.com/There's an option to save the recording to the computer and I capture at a bitrate of 5000 kb/s.
@mkwong98 - I think Boost would handle file Input/Output nicely and it has an API for handling directories in a cross-platform manner. Additionally, most cross-platform GUI APIs will do the same. I am sure WXwidgets is one of them, from what I have seen.
I use SDL for my graphical output. This means using software rendering. I do let the user use OpenGL 2.1 if they desire, but this just blits the final image using a textured quad; the image itself is still rendered in software. I do not draw each tile as a texture; I render the image into a buffer (per-scanline) then convert that buffer into an OpenGL texture. In the future, I will move to OpenGL 3.0 and GLSL, but really only so I can take advantage of pixels shaders :p
And if you can't run OBS (ex. are on Windows XP),
use SCFH DSF instead. You can use VirtualDub for the actual capturing, but you gotta molest a bunch of the settings within VirtualDub before it'll behave semi-correctly with SCFH DSF, but generally speaking any program should let you capture from it since it just shows up as a DirectShow capture device per se. It's performance is pretty much unmatched, as long as the app is using DirectX and not OpenGL.
Tygerbug wrote:
Yie Ar Kung Fu -- I think these are basically the NES sprites:
http://sprite-ripper.narod.ru/sprites/yiearkungfu.pngAren't these the sprites from Mega Drive version of YAKF?
Could be. Too many colors for NES.
Here's a sheet which seems to be correct for NES.
http://www.nes-snes-sprites.com/YieArKungFu.html
On the subject of swapping out backgrounds. I recently picked up NES Remix for Wii U, and many stages in this game do exactly what I previously described, essentially Chroma Keying out backgrounds. The following video should start at 4:00 in, and you can see that not only has the background been swapped out, but the foreground casts a shadow onto it as well.
http://youtu.be/4NppsVK5s_E?t=4mGranted this is a first party Nintendo title, but I'd like to think this more or less indicates that it's possible.
It looks the effect I used in my old
SMB1 speedrun/Rock TV video.
Tygerbug wrote:
There must be something in the later Mega Man games that could be used for an HD reboot. Mobile game "The Puzzle Battle" has some cute redrawn Mega Man 1 sprites .... no idea where to get that game, mind ...
Yes, if the game has sequels on later systems or the game has root in the arcade then I'm sure there will be some artwork which can be useful. And if the game does not have too many designs unique to the series then we can use art from other games too.
asshat818 wrote:
On the subject of swapping out backgrounds. I recently picked up NES Remix for Wii U, and many stages in this game do exactly what I previously described, essentially Chroma Keying out backgrounds. The following video should start at 4:00 in, and you can see that not only has the background been swapped out, but the foreground casts a shadow onto it as well.
http://youtu.be/4NppsVK5s_E?t=4mGranted this is a first party Nintendo title, but I'd like to think this more or less indicates that it's possible.
tepples wrote:
It looks the effect I used in my old
SMB1 speedrun/Rock TV video.
Very interesting videos. If the emulator can output the game graphics directly on top of the desktop then we can put anything we want under it.
So I've drawn most of the necessary Mario sprites for Super Mario 3 and 2 ... as well as most of the necessary Peach and Toad sprites for Mario 2, and a few Luigis (assuming that I can mostly repurpose Mario for Luigi). Only pencil sketches right now, haven't inked or colored them yet. And it's hard to find time with the paid work I'm behind on.
Alex Douglas has implemented my Birdo into SMB2. Here's a quick test. It's running in slo mo so ignore the sound.
https://mega.co.nz/#!q4V1GK4I!EY11AYnOd ... ZzW2NDeMmQ
Completed artwork for the most common Princess Peach behaviors --
http://tygerbug.deviantart.com/art/Prin ... -481940092Unfortunately, even at 4x the original Nintendo size, these sprites will be tiny onscreen.
http://sta.sh/21hjwzzbxo5a
Tygerbug wrote:
Completed artwork for the most common Princess Peach behaviors --
http://tygerbug.deviantart.com/art/Prin ... -481940092Unfortunately, even at 4x the original Nintendo size, these sprites will be tiny onscreen.
http://sta.sh/21hjwzzbxo5aVery good! Can't wait to see them in action.
Super Mario Bros 2 HD Remake! Princess Peach HDNes test by Alex Douglas, art by Garrett Gilchrist.
http://youtu.be/A0Aw-7J4uowDownload the video here:
http://www.mediafire.com/download/g599e ... 1_EV1B.mov
Hmmm... What do you think's better for Birdo? Metal or
DnB?
And to coincide with the above video, here's a zip of the current graphics pack build!
Nice work! Thanks for sharing.
tepples wrote:
Hmmm... What do you think's better for Birdo? Metal or
DnB?
Use both! In theory the emulator can play a different tune for each character.
LittleMike wrote:
游戏过程中的卡顿问题需要解决。
Need to resolve the lag problem during game play
關閉"Generate data for graphics pack editor"功能之後是否仍然有這個問題?
Do you have this problem if you turn of the "Generate data for graphics pack editor" function?
我在"Generate data for graphics pack editor"下选择none,仍然有拖慢现象发生。使用的模拟器是最新版。
笔记本配置:
Intel Core i5-3210M(2.5GHz/L3 3M)
6GB RAM
NVIDIA GeForce GT 640M
LittleMike wrote:
我在"Generate data for graphics pack editor"下选择none,仍然有拖慢现象发生。使用的模拟器是最新版。
笔记本配置:
I selected "none" under "Generate data for graphics pack editor" and it still has the lag problem. I'm using the latest version of the emulator.
Notebook config:
Intel Core i5-3210M(2.5GHz/L3 3M)
6GB RAM
NVIDIA GeForce GT 640M
這樣就只有等到我想出一些讓模擬器加快的方法才會有改善。
In that case, there is nothing to be done until I can think of some ways to optimize the speed of the emulator.
LittleMike,可不可以看看螢幕的幀數設定是不是60?
LittleMike, can you also check the frame rate setting of the screen is 60?
我使用fraps软件来查看帧数。
游戏在正常速度的时候,帧数是60,但是不稳定,有的时候会下降到50左右,当降到50以下的时候,就产生明显的卡顿。
我用于测试的游戏是Yie Ar Kung-Fu
LittleMike wrote:
我使用fraps软件来查看帧数。
游戏在正常速度的时候,帧数是60,但是不稳定,有的时候会下降到50左右,当降到50以下的时候,就产生明显的卡顿。
我用于测试的游戏是Yie Ar Kung-Fu
I used fraps to check the frame rate. When the game ran with normal speed, the frame rate was 60 but not stable. In occasions it dropped to around 50, and there was significant lag when it fell below 50. I used Yie Ar Kung-Fu for the test.
請試試有沒有幫助
Please try to see if it helps your case.
更新 2014-9-30:
Update 2014-9-30:
在顯示引擎加了一個小的速度的修改。
Added a small speed fix to the render engine.
使用了9月30号的版本。
用同样的游戏测试,速度稍稍有一点改进,帧数虽然还是不能稳定在60,但几乎不会掉到50以下了。
楼主亲自测试过吗?是不是和我一样的情况呢
LittleMike wrote:
使用了9月30号的版本。
用同样的游戏测试,速度稍稍有一点改进,帧数虽然还是不能稳定在60,但几乎不会掉到50以下了。
楼主亲自测试过吗?是不是和我一样的情况呢
Tested with the 30/9 version.
Testing with the same game, there is a small improvement with the speed. The frame rate still won't stay at 60 but it rarely drops below 50.
Did author test it yourself? Does it has the same problem as mine?
在正常運作的時候,我沒有遇到模擬器拖慢的现象。只有在開發或錄影時才有這個問題。在開發時帧数原本就已經遠遠低於60,所以這個修正是有幫助但仍沒有60fps。
I don't have the lag problem when running the emulator normally, I only have that problem when debugging or recording. During debugging, the frame rate was far below 60 before, so the fix helps but still no 60 fps.
Hey mkwong. Do you think it would be possible to add APNG support to the emulator? I had someone ask me recently if it would be possible to add extra animations this way. I found this code
http://sourceforge.net/projects/libpng-apng/ and compiled a libpng dll
*link removed*. So far everything works but the animation doesn't play. I think it has to do with the way the image is loaded into memory or it has to be defined in the source code. Either way it would be cool if this can work because then we could add idle animations to sprites if they stand still long enough or have pulsing colors or other changes on something that isn't normally animated like background tiles.
edit:
After looking into this more in-depth it seems like it wouldn't work anyways. APNG is not developed very much and finding SDL_image support and getting it to work is nigh impossible (at least for me). It probably would be better to come up with our own animation system in a traditional sense with multiple images per sheets that it scrolls through.
GGuy wrote:
It probably would be better to come up with our own animation system in a traditional sense with multiple images per sheets that it scrolls through.
Yes, I think the best way to do that is to define our own animation data.
I thought about this function before as tepples suggested something similar earlier in this topic.
The minimal implementation is to define the animation as a sequence of replacement sprites and how many frames each sprite lasts. We also need to define how many idle frames the animation can have before the emulator considers the animation as not in use and resets it.
There are some problems which I can think of:
1. All occurrences of the same animation on the screen will display the same sprite. This can be a problem if there are multiple enemies on the screen and their actions do not sync with each other.
2. The animation always run at the same speed even when the game uses slow motion.
3. The animation always run forward, so if the game repeats sprites backward (eg. ABCCBA) to display a swinging motion then the added frames in the animation will not link up correctly(A1A2-B1B2-C1C2-C1C2-B1B2-A1A2 instead of A1A2-B1B2-C1C2-C2C1-B2B1-A2A1).
4. When the same sprite is use at more than one situation, the the same animation will be shown regardless of the situation.
I think this is an important function which addresses one of the 5 main limitations of NES graphics (number of colours we can use, range of colours we can choose from, the screen resolution, number of animation frames we can fit inside a bank and number of sprites we can have on screen) and I may add this to the emulator in the future. But to do this I think I need to redesign the GUI as it is getting cluttered.
This is really cool guys. I am no programmer by a long shot, but had something like this in mind for some time. I started doing my own mockups a few months ago just to let some of what I had been wanting to do out onto paper/photoshop. My first mockup was from Zelda.
Attachment:
File comment: Zelda Test Mockup
Zelda_mockup_4x_000.jpg [ 353.79 KiB | Viewed 6974 times ]
Following that by Mega Man III. Since MM3 uses a currently supported mapper, I plugged in what I had so far from the Spark Man stage followed by recreating the logo and some text.
Attachment:
File comment: Spark Man 00
20141030103916.jpg [ 392.54 KiB | Viewed 6974 times ]
Attachment:
File comment: MM3 Logo
20141030103859.jpg [ 107.43 KiB | Viewed 6974 times ]
I look forward to the continued development of hdNES. Keep on rocking!
**things I'd like to see**
- controller support
- cheat codes (help with dumping and testing)
Perhaps someone should start a new NES Graphics thread for 32x32 pixel fonts for use with HDNes.
Looking good, Xenobond! I'm sure you could do some very good work in HDNes. I like the font you used on the Mega Man 3 title screen as well.
Mega Man is a good one to experiment on, as a full set of sprites for Mega Man himself would obviously be of use in all the games.
That's part of why I was working on Mario. Should get back to that when I can.
Xenobond wrote:
I look forward to the continued development of hdNES. Keep on rocking!
**things I'd like to see**
- controller support
- cheat codes (help with dumping and testing)
Good work, Xenobond!
Controller support is not on my high priority list, so I'm afraid you have to use joytokey for the time being.
What kind of cheat code features are you looking for? The audio pack feature can be used for cheat codes too.
tepples wrote:
Perhaps someone should start a new NES Graphics thread for 32x32 pixel fonts for use with HDNes.
That will be very useful. I want one for Japanese too, just in case I need to work on Japanese only games.
I've started work on a font pack. It will include all of the default NES colors. Hiragana, Katakana, and English letters. Also special characters such as the copyright symbol and trademark symbol. It should be done within a week.
Edit 1:
Ok here is a quick and dirty 4x font pack for anyone that wants it. I'm thinking of standardizing the layout to match the unicode character table but it's a bit time consuming. Anyways hope this helps!
[Link Removed]
Edit 2: Old link removed.
I just noticed a really strange bug today while testing 4x. I'm running Windows Technical Preview so it might be different for others but when you have your mouse over the game window the emulator slows down. When the mouse is not over the window but somewhere else like the desktop the emulator runs without slowdown. It's quite odd.
GGuy wrote:
Ok here is a quick and dirty 4x font pack for anyone that wants it. I'm thinking of standardizing the layout to match the unicode character table but it's a bit time consuming. Anyways hope this helps!
https://drive.google.com/file/d/0B5aZT1 ... sp=sharingNice! Are you going make another set with the lower case letters for English games?
GGuy wrote:
I just noticed a really strange bug today while testing 4x. I'm running Windows Technical Preview so it might be different for others but when you have your mouse over the game window the emulator slows down. When the mouse is not over the window but somewhere else like the desktop the emulator runs without slowdown. It's quite odd.
Thanks for telling me.
mkwong98 wrote:
Nice! Are you going make another set with the lower case letters for English games?
Yes I'm working on a "standard" set right now that includes a lot of missing things.
mkwong98 wrote:
Thanks for telling me.
No problem.
Edit 1:
The font pack is done!It includes all of the standard NES palette colors, English and Japanese (Hiragana and Katakana) sheets at 4x.
https://drive.google.com/file/d/0B5aZT1 ... sp=sharingEdit 2:
New gradient pack!Attachment:
Blue (Dark).png [ 75.82 KiB | Viewed 6703 times ]
https://drive.google.com/file/d/0B5aZT1 ... sp=sharingEdit 3:
Gold font.Attachment:
gold-example.png [ 33.22 KiB | Viewed 6660 times ]
https://drive.google.com/file/d/0B5aZT1 ... sp=sharing
Wow, very good! Thank you very much!
Update 2014-11-18:
1. Changed the caption of the game window to HDNes.
2. Enabled the window close button.
3. Added an option to change the rate of continuous screen capture.
4. Removed the mouse the cursor from the game window.
GGuy, Please check if the slow down problem still exists. Thanks.
mkwong98 wrote:
GGuy, Please check if the slow down problem still exists. Thanks.
Yes the problem is still there. Fraps reports an drop of 10-20 FPS when the mouse cursor is over the game window (even though it's no longer being drawn). It dips more when the mouse is moved around within the window. It's easy to see the slowdown in Zelda 1 when the text is scrolling during the title screen opening showing all the items.
Probably the problem is handing mouse events, not drawing the mouse.
26-12-2014
1. Disabled a few events which are not in use.
2. Changed the naming of the screen shots so that sorting by name will list them in chronological order.
Graphic pack for "Nuts & Milk (J).nes"
Attachment:
Nuts & Milk (J).zip [436.08 KiB]
Downloaded 309 times
evgeny wrote:
Graphic pack for "Nuts & Milk (J).nes"
Good job!
GGuy, do you still has that problem with the new release?
mkwong98 wrote:
GGuy, do you still has that problem with the new release?
Yes the slowdown is still there with the mouse over the window. It's a 50% slowdown now. Frame rate is cut from 60fps to 30. No dumping or loading graphics just playing it at 4x. 1x is a 5-10fps slowdown and 2x is a 10-15fps loss. I'm thinking it's a Windows 8 (and hence Windows Technical Preview) problem.
Anyone else have this slowdown on Windows 7 or lower?
GGuy wrote:
Yes the slowdown is still there with the mouse over the window. It's a 50% slowdown now. Frame rate is cut from 60fps to 30. No dumping or loading graphics just playing it at 4x. 1x is a 5-10fps slowdown and 2x is a 10-15fps loss. I'm thinking it's a Windows 8 (and hence Windows Technical Preview) problem.
Anyone else have this slowdown on Windows 7 or lower?
So it got worse? I'll update the SDL version to 2.0 in the next release to see if that helps.
evgeny wrote:
Graphic pack for "Nuts & Milk (J).nes"
Attachment:
Nuts & Milk (J).zip
great!
thank you for sharing
evgeny, do you have a youtube footage of the pack? If you do, I can add the link to the first page of this topic.
I was not able to properly record video (framerate, etc).
If someone record it, I will be happy.
P.S.
It would be nice to add certain functions to record video in the emulator.
mkwong98 wrote:
GGuy wrote:
Yes the slowdown is still there with the mouse over the window. It's a 50% slowdown now. Frame rate is cut from 60fps to 30. No dumping or loading graphics just playing it at 4x. 1x is a 5-10fps slowdown and 2x is a 10-15fps loss. I'm thinking it's a Windows 8 (and hence Windows Technical Preview) problem.
Anyone else have this slowdown on Windows 7 or lower?
So it got worse? I'll update the SDL version to 2.0 in the next release to see if that helps.
I'm not sure. I downgraded my graphics card from a GTX 660 to a GTX 460 so that could be the reason.
BTW has lua scripting been suggested or considered? FCEUX has it and it can help expand games without ips patching.
Here's an example of a lua script in action on Metroid.
https://www.youtube.com/watch?v=wp2KV8_wXtA
GGuy wrote:
I'm not sure. I downgraded my graphics card from a GTX 660 to a GTX 460 so that could be the reason.
BTW has lua scripting been suggested or considered? FCEUX has it and it can help expand games without ips patching.
Here's an example of a lua script in action on Metroid.
https://www.youtube.com/watch?v=wp2KV8_wXtAThat is very impressive! I learnt about LUA for TAS but I didn't know it can be this powerful. I'm thinking of a graphics specific script instead. The emulator with run it once per scanline and it will work on the tiles instead of drawing directly on the screen.
I made a short footage of Nuts & Milk graphics pack:
http://youtu.be/bHqG1iVw8u8
mkwong98, thanks.
I was try again record video. Result more productive.
http://www.youtube.com/watch?v=gwORJNKOoqk&feature=youtu.be
Good, I changed the link on the first page.
Nuts & Milk looks great. I need to ink in all my Mario drawings sometime. I never did; I've been doing graphics for my own game.
"SouldreamX" did this drawing for Rockin' Kats ...
http://souldreamx.deviantart.com/art/Ro ... -396287383
Nice find! I admire people who can produce digital art like that.
24-2-2015
1. Updated to SDL2, input settings are incompatible with previous version so please configure input again
2. Fixed some clicking noise in the triangle channel
3. Fixed an overflow bug when filling sound buffer
这次的更新很好!
之前的版本在我的笔记本上运行拖慢的现象,现在已经没有了,运行非常流畅。
I'm working on Astyanax and it is annoying that the same tile is reused at different location in the single large image in cut scenes. So I'm thinking about the script feature. The primary use of the script is to allow the emulator to identify a tile and palette being use in different situations and apply a different HD tile to it. So there are several steps to this:
1. Find out if a specific tile and palette is being used by searching the name table, attribute table and OAM.
2. Find out how the tile is used: e.g. location on screen, values in RAM or variables used by the script.
3. Tag a number to that entry in the name table or OAM. A specific HD tile is previously added to the graphics pack for that particular tile, palette and tag combination.
4. When the emulator renders that tile, it will use the specific HD tile instead of the default one.
For example many tiles are repeated in the title screen of Super Mario Bros. For a particular tile on the screen, the script can find the location of the tile to identify it. However the screen will scroll as the demo starts and so we need to subtract the horizontal scroll value of the map to find out the real location of the tile. Then we tag a number to that tile. Better still, if we know we are in the title screen and the horizontal scroll value, we can immediately identify each entry in the name table and tag them in a loop.
Let's use the standing of Mario as another example. If we can find out whether Mario is standing still, we can start a frame counter and tag the OAM according to the counter to show Mario breathing like in some fighting games. We can also find out the direction that Mario is facing to have more detailed rendering as suggested in an earlier post.
So the emulator needs to provide the following functions:
1. Read from name table, attribute table and OAM.
2. Tag a number to name table and OAM.
3. Read from RAM.
4. Some memory for the script to read and write and the values written persist across frames.
5. A search function to find the existence of a tile.
6. The script will run once per frame
Is that enough to make it work?
Could be good -- could make it easier to do better art for Super Mario Bros and other games where there are a lot of "cheats." I know that the artist who did (some) 2x art for Super Mario got very frustrated at all the cheats present in the original coding.
I am concerned about how it would affect the speed of the emulator. Alex Douglas who did some tests on SMB2 reports that the new version of HDNES runs faster and smoother, allowing for real gameplay (if not recording) at 4x on his computer.
mkwong98, maybe you need to enable replacing tiles and sprites with bigger picture?
For example: 8x8 tile replaced by 8x64, which can owerlap the neighboring repeating tiles.
And sprite limit option needed too.
An alternate idea is to have it possible to mark tiles that are next to each other as a whole. Mario standing is 8 tiles total (2x4) but instead of replacing each tile by itself it replaces it as a whole 64x128 sprite (@ 4x). And then multiple tiles that are used twice can be replaced as well because it's seen as it's own separate object.
Using HEX values from the pattern table in this example.
----------------
| $00 | $01 |
----------------
| $4C | $4D |
----------------
| $4A | $4A |
----------------
| $4B | $4B |
----------------
That's Mario standing.
Mario's second(?) walk frame is this.
----------------
| $00 | $01 |
----------------
| $02 | $03 |
----------------
| $04 | $05 |
----------------
| $06 | $07 |
----------------
As you can see the top 2 tiles are the same while everything else is different. Now if we made it one whole object that is replaced you could edit the top of Mario's head as well and not worry about the tile being used somewhere else unexpectedly. Selecting the tiles to group together could be as simple as clicking and dragging on the captured frame in the editor and pressing a button saying "mark as object"!
I've noticed people prefer/expect to use composite sprite sheets for sprite editing and doing it this way would make those edits usable.
Example with graphics.
Attachment:
combined.png [ 1.99 KiB | Viewed 8143 times ]
Detecting meta-sprites automatically isn't such a trivial task though. But I like the idea of having tiles look different depending on the tiles that surround them.
Yes, both evgeny's and GGuy's ideas are good ideas that I haven't thought of. But I think there is a limitation that the whole object must be in the name table or OAM in order to get recognized. That means it won't work for objects in scrolling background or sprites that can more out of the screen. And for sprites, all the tiles must be placed in consecutive entries OAM, otherwise it will be hard to tell when there are several instances of the same meta sprite flying all over the screen.
You could hook each game's sprite engine and have it write out the display list in some other format.
My idea is similar to a lua script for FCEUX.
Hitbox drawingBut instead of hitboxes it would be metasprites. I don't know how it works exactly because I'm not a programmer but it might be possible with your scripting system mkwong.
Good luck with this however you decide to implement your alternate tile replacement script. It's a much needed feature.
edit: typo
Another idea: add custom parameter. (RAM adress and value)
for example: if RAM $0010=1 then draw tile variant 2, else default.
Maybe use optional RAM, ROM, VRAM, CHROM adresses for check, then anybody can select use pallete or NameTable or game level or anything else as indicator for individual tiles. Also selection custom for byte, word, or double word as value for this.
@mkwong To title screens and fixed images you could do the following:
we have to dump a tile that doesn't repeat.
If the image that we want to replace is a 8 x 8 tile screen we could use the following name patern in the edited tile:
"thenormalnameofthetiledumped-08x08-02-07.bmp"
The 08x08 is the column vs lines the 02 means that the dumped tile was in the second column and the 07 means the dumped tile was in the seventh line.
The file "thenormalnameofthetiledumped-08x08-02-07.bmp" is the whole 08x08 tile image that uses my reference the unic dumped tile in the name file.
Edit: Thinking more this method could be used for everything! It will make the work of dumpers and editors very very easy!
Sorry about my english!
Now that I think about it, the meta-sprite idea may actually work well enough in most cases if I add a restriction to it. The restriction is that the the meta-sprite must be a strip of tiles, so that a big object will be composed of a few vertical or horizontal strips of tiles. If an object only move into the screen from left or right edge, then we can break the object down into vertical strips. This way, we still have the whole meta-sprite to work with even when only part of the object is on the screen. This will also simplify the detection algorithm as it is much simpler to match a strip of tiles to a known pattern.
mkwong98 wrote:
Now that I think about it, the meta-sprite idea may actually work well enough in most cases if I add a restriction to it. The restriction is that the the meta-sprite must be a strip of tiles, so that a big object will be composed of a few vertical or horizontal strips of tiles. If an object only move into the screen from left or right edge, then we can break the object down into vertical strips. This way, we still have the whole meta-sprite to work with even when only part of the object is on the screen. This will also simplify the detection algorithm as it is much simpler to match a strip of tiles to a known pattern.
Great news Mkwong! It will expand the possibilities and will be very easy to edit the graphics!
Awesome! So original and new! I've never seen an emulator like this. It's great! Now, when the cartridge bankswitches, how do you manage to keep track of which sprite goes where?
I think you should do the following
Name every HD sprite as the hex sequence of the sprite's data and 3 colors from the palette. For example: 01020408102040800103070F1F3F7FFF2C2E31
That way every sprite, wherever it comes from, will have its HD sprite.
8bitMicroGuy wrote:
Awesome! So original and new! I've never seen an emulator like this. It's great! Now, when the cartridge bankswitches, how do you manage to keep track of which sprite goes where?
I think you should do the following
Name every HD sprite as the hex sequence of the sprite's data and 3 colors from the palette. For example: 01020408102040800103070F1F3F7FFF2C2E31
That way every sprite, wherever it comes from, will have its HD sprite.
In HDNes, the mappers return the real address of the read so bankswitching is not a problem.
What's the "true address of the read" in Contra or Castlevania or Bee 52?
For CHR RAM games, that will be the address of the last PRG read before writing to CHR RAM.
Do you mean the address of the last PRG ROM read other than an opcode fetch?
Consider a game that copies or decompresses tile data from ROM to $0100-$017F during active picture, waits for vertical blanking, and uses a partially unrolled loop to copy $0100-$017F to video memory. At least Action 53, DABG, and RHDE are known to use a compression library that operates this way. How would your scheme handle this?
I don't have any idea how to add HD support to those games yet. May be I'll add an option to select how to identify the tiles: PRG ROM address + tile data, PRG ROM address only or tile data only. Then those game will have to use the tile data only and ignore the PRG ROM address. This may cause problem if several different tiles have the same tile pattern and palette but this is the best I can come up with.
May be use tile number in VRAM (tile adress) + tile graphics data (hex data of graphic tile) for VRAM games?
A method for parallax scrolling.
I don't know how the emulator renders the frame but I was thinking today about how to implement parallax scrolling on solid color backgrounds or any background in general.
Using
PPUSCROLL as the base we can determine where the camera is. Because that is default NES behavior used in most games. In the parallax settings tab we will have a setting to determine the speed in which the background image scrolls when compared to the PPUSCROLL location as well as tell it which picture to load per screen similar to the music having to define one or more addresses for it to take effect. So if the address is 0D for example show this for the background and if it’s 1B then show this one if you’re clever you might use the same music addresses for this effect. Since the background color is actually blank and determined by the game itself no special green screen color replacement is needed. It will just draw the image instead of transparency and then draw the tiles on top. Multiple images can be used for the background to create multiple parallaxes each with their own separate speeds. Think Super Mario All-Stars. Like I said I don’t know how the frames are drawn but all it would need is a way to render the background image independent of the game and then draw the replaced game sprites and tiles over it.
That's my idea. Forgive me if anything is incorrect or the information is invalid. My knowledge of how the NES works is next to nothing.
evgeny wrote:
May be use tile number in VRAM (tile adress) + tile graphics data (hex data of graphic tile) for VRAM games?
Do most games use fixed CHR RAM address for the same tile? If they do then this may work.
GGuy wrote:
A method for parallax scrolling.
I don't know how the emulator renders the frame but I was thinking today about how to implement parallax scrolling on solid color backgrounds or any background in general.
Using
PPUSCROLL as the base we can determine where the camera is. Because that is default NES behavior used in most games. In the parallax settings tab we will have a setting to determine the speed in which the background image scrolls when compared to the PPUSCROLL location as well as tell it which picture to load per screen similar to the music having to define one or more addresses for it to take effect. So if the address is 0D for example show this for the background and if it’s 1B then show this one if you’re clever you might use the same music addresses for this effect. Since the background color is actually blank and determined by the game itself no special green screen color replacement is needed. It will just draw the image instead of transparency and then draw the tiles on top. Multiple images can be used for the background to create multiple parallaxes each with their own separate speeds. Think Super Mario All-Stars. Like I said I don’t know how the frames are drawn but all it would need is a way to render the background image independent of the game and then draw the replaced game sprites and tiles over it.
That's my idea. Forgive me if anything is incorrect or the information is invalid. My knowledge of how the NES works is next to nothing.
The PPU can only hold the map data upto 2 screen wide and it is up to the program to load new data and overwrite the old as the screen scroll. So the scroll values inside the PPU alone is not enough to determine the real scroll value. The best bet is to find the scroll values directly from RAM and calculate the real scroll value with a formula. Both the formula and the RAM address will be game specific.
So long as the scroll amount doesn't change by more than about 100 pixels from one frame to the next, you can guess how far it's scrolled. For example, if the scroll in successive frames is 509, 511, 1, then 3, you can probably guess that it has wrapped.
Quote:
Do most games use fixed CHR RAM address for the same tile? If they do then this may work.
Games use nametables and sprite attributes for static tile address, why something should be shifted? Yes, the same addresses can be downloaded new tiles, but the image data (in hex) will be different and it can be determined that it is a different tile. May be to slow compare all 16 bytes of tile data, then may use partially data or hash, checksum.
mkwong98 wrote:
The PPU can only hold the map data upto 2 screen wide and it is up to the program to load new data and overwrite the old as the screen scroll. So the scroll values inside the PPU alone is not enough to determine the real scroll value. The best bet is to find the scroll values directly from RAM and calculate the real scroll value with a formula. Both the formula and the RAM address will be game specific.
I see, well it was worth a shot. I just figured if the value went up in RAM then scroll right and if it went down scroll left. I didn't think about when it resets. I was looking at addresses $2005 and $2006 in Super Mario Bros 1 and $0022 and $0023 in Super Mario Bros 3. It would have been a cheat way to do it anyways probably.
edit: so I figured out that $2005 in SMB is one pixel and $2006 is one 8 pixel block. So basically you just gotta count and keep track of it. Some kind of counter value that stays behind the scenes. And that would translate into 1 pixel on the PNG background file (which can loop or be as long as the level). Or if you set it 1 pixel per 2 hex values or whatever. 2 pixels per 1 hex etc. Then hopefully that would produce parallaxing. The lowest layer on the emulator would be an image viewer essentially that the emulator plays on top of. Anything marked transparent in the palette or transparent in the png would of course show the image on the bottom layer.
edit 2: or maybe not. You guys know more about the system then I do.
mkwong98 wrote:
8bitMicroGuy wrote:
Awesome! So original and new! I've never seen an emulator like this. It's great! Now, when the cartridge bankswitches, how do you manage to keep track of which sprite goes where?
I think you should do the following
Name every HD sprite as the hex sequence of the sprite's data and 3 colors from the palette. For example: 01020408102040800103070F1F3F7FFF2C2E31
That way every sprite, wherever it comes from, will have its HD sprite.
In HDNes, the mappers return the real address of the read so bankswitching is not a problem.
What about Battletoads where the player sprites are loaded by copypasting from PRG-ROM to CHR-RAM?
mkwong98 wrote:
I don't have any idea how to add HD support to those games yet.
"Those games" presumably include
Battletoads.
tepples wrote:
mkwong98 wrote:
I don't have any idea how to add HD support to those games yet.
"Those games" presumably include
Battletoads.
And my game NESCraft. All sprites are loaded on unused tiles on demand from PRG-ROM because there will be more mobs and player sprites than it's possible to fit 1KB banks at the same time.
mkwong98, as I said:
8bitMicroGuy wrote:
Name every HD sprite as the hex sequence of the sprite's data and 3 colors from the palette. For example: 01020408102040800103070F1F3F7FFF2C2E31
That way every sprite, wherever it comes from, will have its HD sprite.
This above is hexadecimal data of a tile and then the 3 colors of the tile. If this won't be implemented, then my game won't be HD
I'll focus on CHR RAM games once I finish adding the meta-sprite function and make a graphics pack for Astyanax.
mkwong98 wrote:
Hi, I recently resumed working on my emulator and now I think I have enough to show. The gimmick of the emulator is the ability to display custom true colour tiles at up to 4x resolution.
Link:
See the attachment of the third message
BombSweeper is used as an example and a simple 2x graphics pack is included in the files which replace the number tiles. You need to download and put BombSweeper.nes inside the rom folder. You can play around with the png files inside the BombSweeper folder and see the results. The emulator is still in early stage and so lacks many standard features. Please read the readme for the limitations before using it. Feel free to comment and please let me know if you have trouble running the emulator on your machine.
Thanks.
Hi this emulator is extremely impressive
http://www.emutalk.net/threads/55446-ne ... ario-hdnes! but are there any plans to increase accuracy, compatibility and add support for the missing mappers? Are tiles with resolutions higher than 4x possible? xBRZ filter would be very good too.
http://sourceforge.net/projects/xbrz/files/xBRZ/By the way what do you think about a libretro port?
Nesd4 wrote:
Hi this emulator is extremely impressive
http://www.emutalk.net/threads/55446-ne ... ario-hdnes! but are there any plans to increase accuracy, compatibility and add support for the missing mappers? Are tiles with resolutions higher than 4x possible? xBRZ filter would be very good too.
http://sourceforge.net/projects/xbrz/files/xBRZ/By the way what do you think about a libretro port?
Thank you. My plan is to make graphics pack for a few games to see what the emulator still needs and implement them. After this I'll work on performance, accuracy, compatibility and missing mappers. Once the performance is good enough, I'll think about higher resolutions and filters.
My idea is that since the palette of NES is so limited, it will greatly improve the filter if it is designed to be NES palette specific filter rather than a general filter. This mean the emulator will output the screen as an array of color indexes and the filter will output the final color.
I don't know much about libretro so I'll have a look, thank you for suggesting.
mkwong98 wrote:
Nesd4 wrote:
Hi this emulator is extremely impressive
http://www.emutalk.net/threads/55446-ne ... ario-hdnes! but are there any plans to increase accuracy, compatibility and add support for the missing mappers? Are tiles with resolutions higher than 4x possible? xBRZ filter would be very good too.
http://sourceforge.net/projects/xbrz/files/xBRZ/By the way what do you think about a libretro port?
Thank you. My plan is to make graphics pack for a few games to see what the emulator still needs and implement them. After this I'll work on performance, accuracy, compatibility and missing mappers. Once the performance is good enough, I'll think about higher resolutions and filters.
My idea is that since the palette of NES is so limited, it will greatly improve the filter if it is designed to be NES palette specific filter rather than a general filter. This mean the emulator will output the screen as an array of color indexes and the filter will output the final color.
I don't know much about libretro so I'll have a look, thank you for suggesting.
I left you a private message.
Not much, don't have time to work on it for the past few months due to work. Now my workload is a bit lighter, I'm working on this again. Currently the screen is stored as lots of strips (one strip is one row from a tile). Now I'm planning a big rewrite of the screen rendering part for the following:
1. group the related strips back into a tile so that the emulator can recognize meta sprite patterns
2. store graphics in the texture cache in tile form instead of strips
3. split the texture cache into standard size and HD size
4. reduce a volume of redundant work by having a better way of storing and searching texture data across frames
Then I'll need to update the GUI to handle meta sprite. I hope to make a release before the end of the year but don't count on it.
Thank you for your interest!
mkwong98 wrote:
Not much, don't have time to work on it for the past few months due to work. Now my workload is a bit lighter, I'm working on this again. Currently the screen is stored as lots of strips (one strip is one row from a tile). Now I'm planning a big rewrite of the screen rendering part for the following:
1. group the related strips back into a tile so that the emulator can recognize meta sprite patterns
2. store graphics in the texture cache in tile form instead of strips
3. split the texture cache into standard size and HD size
4. reduce a volume of redundant work by having a better way of storing and searching texture data across frames
Then I'll need to update the GUI to handle meta sprite. I hope to make a release before the end of the year but don't count on it.
Thank you for your interest!
Any further news? By the way is tile replacement in HDNes purely software rendering or is it done on the GPU?
Nesd4 wrote:
Any further news? By the way is tile replacement in HDNes purely software rendering or is it done on the GPU?
Not much news, can't find much free time to work on it
The replacement is done on the GPU.
I see someone else did Super Mario Bros. Would love this graphics pack, though I wouldn't be able to resist reworking it. If I had time.
https://www.youtube.com/watch?v=NfqtOXZoyVo