The future of emulation? Is it possible with zsnes?

[Breadfan]

But zsnes runs the very 2dimentional SNES games. Creating packs to over-ride the graphics would be exactly the same as recreating the game to your own tastes.
Hmm.. Let me think about the amount of work involved...
All sprites redrawn and reanimated (something papermario does not do (It only swaps textures)), All backgrounds redrawn and rescaled (I'll refrase, the the entire freakin world redrawn.), not to mention the millions of bugs that will be undoubtedly squirming around, due to scaling problems. And I cant even begin to imagine the emulation problems, implementing, and executing at a decent speed (with speed, I mean without the need to implement loading screens.).
Its possible, yeah, but who gives enough crap to care about remaking classics into modernday wannabes, It would make the majority of the zsnes fanbase, turn green.
That said; to zsnes development: Please implement such a cool feature! I really want to play a fanmade sprite of Samus Aran. It would be all big and cool!

[Jikmo]

of course you'd have to redraw a lot, which is why it would take a lot of work to make new graphics, but simply implementing it wouldn't be too much work.

and what do you mean by reanimated? i thought animation in snes was achieved by just swapping sprites/tiles. so you just keep all of the highres pics to the same aspects of the original, and you've already got the animations

all you would need to do is redraw certain tiles in the snes games, then whenever the game would request those tiles, it would use the new highres ones instead

of course it would be more difficult than in n64 because with n64 all you do assign the new texture to the polygon. you barely even have to have any new code at all. with snes you'd have to worry about having multiple tile sizes and getting them to come out the same

ive never looked through the snes9x code, but if i have some time today, i will

[Jikmo]

I didnt know they made a paper mario 2 for n64

anyway, N64 games use 3D style things to handle their graphics, and games NOT in 3D tend to be much hard to manage with that feature. granted, its a nice thought, very few if anyone owuld be willing to redo an SNES game, especuially when there so little benefit for it. The huge amounts of work required would be incredible as well...And what about translation patches or hacks? The graphics wouldnt work right then if things moved and expanded, not to mention having to dump those textures since EVERYthing on the SNES is pretty much a texture anyway. Think of the poor vram hehanywa... neat idea, not to easy and efficant to do, and not worth the time. Time spent coding this is better spent correcting the timing and such. However, if you think differently, fire up cvs.exe and have a go : ) just dont rely on someone else to implemnt such a pointless feature...

the graphics wouldnt be placed inside the game chris or even inside the vram, they'd be distributed separately, and in the emulator, they'd probably be stored separately. think of it as a pointer. when the emulator looks for the tile, it instead encounters a pointer that says to look in a table for a picture to be used in place of the tile (though it wouldn't be implemented quite like that unless there's any way to check to see if the tile is not used, like if there's any piece of code that you would never encounter in a tile. however, since i don't know much about the snes, i'd assume that there is nothing like that. it would probably be implemented by just having it check a table to see if the tile has another picture stored elsewhere)

btw, for any one who's hoping for very nice graphics, sorry, you'd still be limited to the 256 color pallette used in whatever scene the sprite is used, and if portions of the pallette change and only a small part is reserved for that sprite, then you'd be limited to the small part of the pallette that's reserved for the sprite. so shading and the such probably won't be possible. otherwise, you'd have to redesign the pallettes and every graphic in the game. it would be a lot of work to implement the feature and an unwieldy task to redesign the graphics of a game.

though if certain image formats would be used (not that i know any, just hypothetically), it would be possible to have gradients or even intermediate colors (like say color 1 is green, and color 2 is blue, you could set a pixel to be 75% of the way between color 1 and color 2) though this would take a lot of new code and the emulator would likely run very slowly whenever new tiles are loaded or the pallette is swapped

in other words, other innovations are possible, but if the feature would be implemented, it would only be feasible to use it to make higher res sprites without any improvement in the colors

[daft]

None of these arguments make sense. Converting a whole game doesn't have to be a lot of work.

If you've been over to the High-Res forum for the n64 plugin, you'd notice there are hundreds of people working together on textures and sprites. If you look into Zelda64, there's atleast 20 photoshoppers in there constantly posting high-res graphics each day.

They've seriously redone half the game in only a few months. This isn't pointless, and if the scaling is coded right in the begining, no one should have to worry about scaling issues.

Like Jikmo said, this feature will eventually be ported to most systems. I just hope ZSNES will support it first so it doesn't have to be made compatible with some half-assed implementation another snes emulator uses.

[Breadfan]

I think I'll stay pessimistic about this kind of development. Snes emulation has been developing relitively slowly as it is... I have a feeling it would take another four years before we see any kind of decent result.

If you've been over to the High-Res forum for the n64 plugin, you'd notice there are hundreds of people working together on textures and sprites. If you look into Zelda64, there's atleast 20 photoshoppers in there constantly posting high-res graphics each day.

They've seriously redone half the game in only a few months.

The majority of replaced textures of a game like Zelda have been replaced by scanned images, or upscaled/processed textures. The only way people got interested in retexturing papermario is because of the same feature exists in the Gamecube emulator (which means they can easily swap all the characters with the papermario 2 ones).
Would a scanned image look convincing in 256 colour? Probably not.

This isn't pointless, and if the scaling is coded right in the begining, no one should have to worry about scaling issues.

I admit, I was simply talking out of my ass to get my point across.

[Jikmo]

I think I'll stay pessimistic about this kind of development. Snes emulation has been developing relitively slowly as it is... I have a feeling it would take another four years before we see any kind of decent result.

It's been developing slowly because there haven't been any new developments in the past few years. I remember being extremely excited when the first sound appeared in snes emulators. And when people decided to try cracking the chip in Star Ocean, there was a huge bustle and snes emulation in general got a large boost in production.

Some completely new innovation like this is just what emulation needs. Emulation is now not only a way to play your old games, but to play them with features that the old games never had. Improved graphics, remastered sound, someone will some day make an implementation that will allow for vastly improved colors using either the intermediate color suggestion that i made or simply using 16 bit graphics (though some odd hack would have to be used for fadeout effects that are achieved through shifting the pallette to a certain shade, so the former solution would probably be more feasible)

So what's with people being so against this feature? I haven't looked at the code for zsnes or snes9x yet (sorry... umm... i fell asleep...) but if the graphics code is done correctly, it shouldn't be very difficult to implement.

I bet next for emulation, they'll be trying to replace the music and then they'll try to replace individual files or parts of files such as models. Not sure how well the modelling thing'll work, but I'm sure someone will try it, and if it actually works, it would be sweet. Imagine playing FF7 with remastered sound, high res textures, and high polycount characters. Oh... i'm salivating... i've never beaten that game, it'd give me a good excuse

[Neo Kaiser]

So what's with people being so against this feature? I haven't looked at the code for zsnes or snes9x yet (sorry... umm... i fell asleep...) but if the graphics code is done correctly, it shouldn't be very difficult to implement.
[/quote]And how do you know that it shouldn't difficult to implement? Are you a coder? If so you could implement them yourself if you are not code you should shut up.

[Jikmo]

So what's with people being so against this feature? I haven't looked at the code for zsnes or snes9x yet (sorry... umm... i fell asleep...) but if the graphics code is done correctly, it shouldn't be very difficult to implement.

And how do you know that it shouldn't difficult to implement? Are you a coder? If so you could implement them yourself if you are not code you should shut up.

dude, seriously, what the fuck?

Yes, yes I am a programmer. I already said that I'd look at the code and see what i can do. I can't say that I'd come up with the best solution since I'm not at all familiar with the snes9x or zsnes code. I'll try to hack something together, but I can at least give it a shot

what's your problem?

[Neo Kaiser]

So what's with people being so against this feature? I haven't looked at the code for zsnes or snes9x yet (sorry... umm... i fell asleep...) but if the graphics code is done correctly, it shouldn't be very difficult to implement.

And how do you know that it shouldn't difficult to implement? Are you a coder? If so you could implement them yourself if you are not code you should shut up.

dude, seriously, what the fuck?

Yes, yes I am a programmer. I already said that I'd look at the code and see what i can do. I can't say that I'd come up with the best solution since I'm not at all familiar with the snes9x or zsnes code. I'll try to hack something together, but I can at least give it a shot

what's your problem?

Nothing go ahead no one will stop you! It is just that saying that something is easy to implement without looking to the code is out of the question.

[funkyass]

The effeciency of this idea originally hinges on the fact that you have 3d hardware to work with.

Its not true with snes emulation. yes we do use opengl, but thats to display the final image, not the actual rendering.

The SNES is capable of switching the order of the 5 layers it works on a per-pixel basis; so in properly doing higher-res images, you need to take that in consideration - you need all five layers using tiles of the same dimensions, and not piece meal like how 3d hardware handles texures.

If you decide to use higher-res tilessets, you'd also need to deal with any timing issues that would be incured by having the PPU code work on more lines of resolution

[creaothceann]

I really want to play a fanmade sprite of Samus Aran. It would be all big and cool!

Super Metroid's sprite is big enough IMO, and for the NES you can use this patch.

[Nightcrawler]

I can't believe this arguement has continued. You're not going to be able to do this with ZSNES. Explain to me how you would do this?

You cannot texture swap something that isn't even drawn with textures. ZSNES draws the screen to a buffer in memory which becomes a surface in DirectDraw and I assume a surface in OpenGL( I didn't look at the linux code) There is no cataloging of graphics. No way to identify any graphical data in any game. No way to swap or do anything with textures since there ARE NONE. There is absolutely no 3d hardware rendering and the graphics card pipeline isn't even used.

I would challenge you to rewrite ZSNES to use 3d drawing methods that would rely on textures AND have the ability to do the texture swap because you'd need ZSNES to identify graphics in each game it's used in. I honestly don't think you could do it.. and if I underestimate your programming ability, I certainly don't think you could do it this year or most likely next. It would require a large amount of restructuring and recoding. You don't think it will.. then prove me wrong and look at the source and explain to me how you are going to do this because if you ask me, it's just not going to happen.

[grinvader]

Well, my 2 cents about all this.

Replacing sprites can theoretically be done.
If you look at how ZSNES used to handle Star Ocean and Street Fighter Zero/Alpha 2, and how it handles SPC7110 games still, that's what we do.
After a team reverse-engineered the sprite data location and dumped them manually, ZSNES uses a hack to load this data from external files instead of looking inside the ROM.

You can replace tiles, sure. However, if you want to change the resolution, you don't need a SNES emulator, you need something else.
The whole 'hi-res tiles' thing is moot without rewriting the entire graphic engine (not just the renderer).
You'd have to draw everything at a huge res, since you're working with 2D planes. You can't say 'this 8x8 area will hold a 64x64 hires tile' without scaling it down, making the res increase useless to begin with.

You'd be better off trying to create a badass new graphic filter, it'd be much faster and easier to add in current emulators...

Or start your own emulator from scratch, making your graphic engine so that tiles, once decoded, are pasted on 3d surfaces.
That way, you'd just have to redraw every tile in the ROM at a higher res and reference all of their ROM locations in a big nice index file for your emu to run SNES games using high-res tiles !
You'll also want to make this engine 32-bpp based, so that your hires tiles can use more colours...
Basically, you'd have:
if (no hires tile)
-> get data from ROM, draw tile using SNES palette, then bring it up to 32bpp, and map it on a quad.
else
-> get data from external file (already 32bpp) and map it on the quad.
Proceed with next tile.

Good luck with that.

[blackmyst]

A problem with this whole thing is the tiling of graphics and the reuse of tiles. Often you'll see backgrounds that rely heavily on the tiles having a certain resolution, a certain amount of pixels in the right places, to somewhat seamlessly fit together and make a nice picture (while still allowing reusability of tiles in the same scene). At a higher resolution with supposedly more gradience and non-aliased lines, the seams are going to stand out a lot more. Coupled with the fact that an increased resolution will do nothing against the tiled look of levels as opposed to backgrounds in more modern 2D games that are composed of larger pieces, or simply of one large single drawn picture, it'll all look very ugly indeed.

A possible solution? Drop the SNES graphics engine alltogether, just have it output some values that are normally passed to the GPU (I'm just assumming it's actually that simple*), and write a new one that will allow to show anything that one's graphics API of choice is able to do. You could have fully handdrawn backgrounds without tiling. Or prerendered ones, hell, you could even have 3D (though that wouldn't be my preference). Add bump mapping and pixel shaders, extra effects on cue with certain events, wherever the hell you want.

You wouldn't have to worry about anything on the SNES' GPU side of things, which would be the case if you were to simply replace tiles. And you wouldn't have to worry about what goes on in the bowels of the gameplay engine, which would be the case if you were to do a remake from scratch.


*(if anything gives you trouble you could just leave the GPU running, it's not like it would matter much on today's PC's. Jeez, even I could probably write such a thing if I were to just make a frontend that spies on, say, Super Metroid's variables and makes changes to the graphics overlay accordingly. Though I don't really have the Windows knowledge to even make a frontend. Hey, anyone want to team up? :p)

and what do you mean by reanimated? i thought animation in snes was achieved by just swapping sprites/tiles. so you just keep all of the highres pics to the same aspects of the original, and you've already got the animations

I think you misunderstand the meaning of the word "animation."

[Nightcrawler]

Right.. each game would have to be reverse engineered and indexed to know where the graphics are.

You forgot one other thing Grin.. If you rewrote the emulator to use textured quads, how would you handle HDMA or per pixel effects? That's going to add one even more complexity.

[blackmyst]

Right.. each game would have to be reverse engineered and indexed to know where the graphics are.

Was this a reply to my post?

If yes: I think you didn't read it very carefully, I said nothing about actually using any of the game's original graphics.

If no: Uhh, never mind. :>

[grinvader]

You forgot one other thing Grin.. If you rewrote the emulator to use textured quads, how would you handle HDMA or per pixel effects? That's going to add one even more complexity.

Pretty much. I completely forgot those... -_-

[daft]

Ok, so it'd be a pain in the ass to add without breaking things. I figured as much.

Would ZSNES' future OpenGL support have any relevance here?

[blackmyst]

Ok, so it'd be a pain in the ass to add without breaking things. I figured as much.

Would ZSNES' future OpenGL support have any relevance here?

That has no influence whatsoever on the emulation itself. Like every other "extra" feature, it's just something on top of the Virtual Snes. This tile replacement thing goes deeper than that.

My version, however, involves just another layer of app added on top.

[Jikmo]

The SNES is capable of switching the order of the 5 layers it works on a per-pixel basis; so in properly doing higher-res images, you need to take that in consideration - you need all five layers using tiles of the same dimensions, and not piece meal like how 3d hardware handles texures.

If you decide to use higher-res tilessets, you'd also need to deal with any timing issues that would be incured by having the PPU code work on more lines of resolution

ah, hadn't thought of that...

What i was thinking of doing was having a new graphics mode where everything is drawn onto a surface at 4x the resolution. for normal tiles, it would just draw the pixel 4 times, then when it would get to a tile that's to be replaced, it would draw a block of 4 pixels so that the lines would still be proportionally the same size, just 4x the resolution

to locate the tiles, i was planning on just using a tile dumper (which would of course only work for games without special chips). they give you the address at which the tile is located, so i was simply going to check when that address would be accessed

sure it would be very hacky and probably extrememly slow, but since i dont know much about the zsnes or snes9x code, i just wanted to hack something up.

and of course, now im doubting the possibility of what i was thinking of doing.

in the snes9x render code, does the Tile parameter at all corrospond with the tile in memory in the game or even the tile in memory in the emulator? and if it does, is this value unique to each tile at all or does it corrospond to a different tile at different parts of the game? It seems to be that that number is transformed and added to an offset to get the location of the tile in memory but i could just be looking at the code under a tinted glass of wishful thinking.

is any of this code documented anywhere?

edit: blackmyst, if you're seriously thinking of undertaking a project like that, I'd like to help

[Gospel]

don't let the graphics whores come and shit all over the snes please

[kieran_]

They have a cel-shading plug-in now.

[Nightcrawler]

Right.. each game would have to be reverse engineered and indexed to know where the graphics are.

Was this a reply to my post?

If yes: I think you didn't read it very carefully, I said nothing about actually using any of the game's original graphics.

If no: Uhh, never mind. :>

No.. your post did not exist when I was writing mine as you wrote yours a minute before I wrote mine.

But since I see it now. What you are proposing will not work either.
How would your overlay engine know what to overlay? You still have the problem that your 'frontend' does not know what it is looking at.

[Nightcrawler]

The SNES is capable of switching the order of the 5 layers it works on a per-pixel basis; so in properly doing higher-res images, you need to take that in consideration - you need all five layers using tiles of the same dimensions, and not piece meal like how 3d hardware handles texures.

If you decide to use higher-res tilessets, you'd also need to deal with any timing issues that would be incured by having the PPU code work on more lines of resolution

ah, hadn't thought of that...

What i was thinking of doing was having a new graphics mode where everything is drawn onto a surface at 4x the resolution. for normal tiles, it would just draw the pixel 4 times, then when it would get to a tile that's to be replaced, it would draw a block of 4 pixels so that the lines would still be proportionally the same size, just 4x the resolution

to locate the tiles, i was planning on just using a tile dumper (which would of course only work for games without special chips). they give you the address at which the tile is located, so i was simply going to check when that address would be accessed

sure it would be very hacky and probably extrememly slow, but since i dont know much about the zsnes or snes9x code, i just wanted to hack something up.

and of course, now im doubting the possibility of what i was thinking of doing.

in the snes9x render code, does the Tile parameter at all corrospond with the tile in memory in the game or even the tile in memory in the emulator? and if it does, is this value unique to each tile at all or does it corrospond to a different tile at different parts of the game? It seems to be that that number is transformed and added to an offset to get the location of the tile in memory but i could just be looking at the code under a tinted glass of wishful thinking.

is any of this code documented anywhere?

edit: blackmyst, if you're seriously thinking of undertaking a project like that, I'd like to help

You just keep ignorning what I have to say when I keep pointing out why applying this principle to ZSNES or SNES9x is not going to work. But I'm going to do it again anyway.

You're tile dumper will not give you the locations of graphics for more than 25% of games if you're lucky. You underestimate the fact that many games including the ever so popular Zelda 3 and Super Mario World contain compressed graphics. You won't see them in a tile dumper. You may see a few uncompressed graphics, but you're limited to whatever you see there.

I can't count the number of games I've looked at that have compressed graphics of some sort, but I can count the number that have been fully uncompressed on my fingers.

From your post here, you have pretty much shown you don't know much of anything about the SNES. Without such knowledge, you cannot do what you are proposing. I'll continue to be nice.. and explain..

Each background uses a tilemap referencing tiles in VRAM. The tilemap can change at any given time, as well as the VRAM data. The data that is in VRAM could have gotten there from being created in RAM or directly from the ROM. There is absolutely no correspondence between locations in the ROM,RAM, VRAM, and/or tilemap data. Even the start of the tilemap and tile data in VRAM is user definable. And as I said.. all of these variables aside from a ROM location can be changed at any time. You will not be able to 'replace' any graphics without reverse engineering the game. You may be able to get away with SOME graphics that are indeed uncompressed.. but you still have the daunting task of adding an recognition index for that game to the emulator. And I'll tell you what.. I'd bet mixing hi resolution graphics with the low(even LOWER than standard N64 graphics) standard SNES graphics will look like crap. You'd have to do the entire game.. which of course there is an extremely high chance that some of the graphics are compressed. Darkforce and whomever else worked on the Star Ocean graphics packs did a HUGE amount of work to make that possible that very few people if anyone else could have done and that's coming directly from the horses mouth.

By the way, sprites are another story altogether and use object data in the form of OAM tables stored in VRAM. I'm not going to get into that though. I'm done talking for now.

[blackmyst]

No.. your post did not exist when I was writing mine as you wrote yours a minute before I wrote mine.

But since I see it now. What you are proposing will not work either.
How would your overlay engine know what to overlay? You still have the problem that your 'frontend' does not know what it is looking at.

What do you mean by how would it know what to overlay? It overlays everything. o.o

You ditch the whole tile engine (or leave it running, who cares) and simply paste homemade graphics with a homemade engine on top. It's a whole separate app that you see on screen. Just take the absolute minimum amount of information that you need to know from the program for gameplay purposes, say, foreground scroll x and y (you can think of your own method to scroll backgrounds since those don't have an impact on gameplay anyway most of the time, and if they do, well, just find those values too), any tileswaps that happen, x and y locations of sprites on the screen and what they're doing in terms of animation.

How do you find these values? Same way as you find cheat codes. Or it could be even simpler maybe, since you only need to know what the main CPU sends to the GPU. Every "graphics pack" would have a little precompiled list of memory adresses that it needs, that's how it knows what it's looking at.

Lots of work to do? Sure. But remember what this whole topic is about in the first place....completely redrawing a game's graphics. That's no small task to begin with.




I'm not a graphics whore, I'm a fierce proponent of original SNES quality, I even play with either interpolation together with 25% scanlines, or TV-out, and I prefer that over things like HQXX (which I personally think is way overrated with its inability to handle more complex SNES graphics, which, if you think about it, covers a LOT of games).

However, if you're gonna do something to improve the graphics, you might as well do it right. And I already explained why I think simple tile replacements are not a good way to do it.