hate to be that guy...
but when is neimod gonna stop being a dweeb and release somthing...?
When its ready.
Things take time and I'm sure he does other things also besides hacking.
hate to be that guy...
but when is neimod gonna stop being a dweeb and release somthing...?
It'd be one thing just to release the exploit as it is, but making an emulator or anything takes time too.yeah, that's true...
I don't even want 3ds roms, I just want homebrew like emulators
When are YOU going to release something?hate to be that guy...
but when is neimod gonna stop being a dweeb and release somthing...?
Are you against stretching or anything? you only stretches very litte to fill the gaps and its only on the background layers.As I said, there is no need to stretch at all. There is only a 4 pixel difference on either side, just clipping those 4 pixels off would prevent any leaking of the layers while at the same time preserving a 1:1 pixel ratio, keeping the image almost exactly as it would be on SNES hardware (ish). My point still stands.
Are you against stretching or anything? you only stretches very litte to fill the gaps and its only on the background layers.
Basicaly you will still have the 1:1 experience if you dont stretch the layer the sprites interact with and that layer and the sprites at 0 depth.
Stretch = blur, blur = ugly. Especially on a low resolution system like the SNES, even more so when there will be only a small amount of stretch. It also seems that I misunderstood your original statement, I assumed that you meant the stretching would be required for the 3D effect to work, not that it could be used to hide some of the edges.
As for what SparroHawc said about it being too much work, I can't see how. SNES9x already allows the user to enable/disable each bg layer, which proves a couple of things, 1. the layers are already rendered seperatly and 2. the emulator already knows the priority of each layer, or else it wouldn't be displayed correctly to start with.
Really all that needs to be done, even i it is on a per game basis, would be to render one display as-is, then a second with the layers shifted to the side (by different amounts of course). All of which can be don automatically as the emulator already knows which layer is in front, which is second etc. "It's a minor gain for a lot of work" is just a way of saying "I don't want to", which is fair enough.
I was thinking about this a long time ago too, and I thought about the layers dilemma. If someone could come up with a system so that it could be left up to the community to define how the 3D works, then it wouldn't be much work for the developers, they'd only have to implement the engine. So, a basic system might be a config file that defines layer offsets for a particular mode or when a memory offset is at a particular value. A more advanced system could use a scripting engine, like V8 or something (JavaScript is a very easy to learn language), using callbacks and host functions to change the display as and when necessary.Stretch = blur, blur = ugly. Especially on a low resolution system like the SNES, even more so when there will be only a small amount of stretch. It also seems that I misunderstood your original statement, I assumed that you meant the stretching would be required for the 3D effect to work, not that it could be used to hide some of the edges.
As for what SparroHawc said about it being too much work, I can't see how. SNES9x already allows the user to enable/disable each bg layer, which proves a couple of things, 1. the layers are already rendered separately and 2. the emulator already knows the priority of each layer, or else it wouldn't be displayed correctly to start with.
Really all that needs to be done, even i it is on a per game basis, would be to render one display as-is, then a second with the layers shifted to the side (by different amounts of course). All of which can be don automatically as the emulator already knows which layer is in front, which is second etc. "It's a minor gain for a lot of work" is just a way of saying "I don't want to", which is fair enough.
That makes little sense. If the layer for the ground is the same as the layer for the trees, how would Link be able to run behind them?EXAMPLE: TLOZ - A link to the Past. The background layer that shows the ground is actually the same layer the shows the trees and the treecrowns (you can run under those)
So if you elevated link to be higher up than the ground then you would automatically be higher up than the treecrowns aswell and that would look very ugly.
I was thinking about this a long time ago too, and I thought about the layers dilemma. If someone could come up with a system so that it could be left up to the community to define how the 3D works, then it wouldn't be much work for the developers, they'd only have to implement the engine. So, a basic system might be a config file that defines layer offsets for a particular mode or when a memory offset is at a particular value. A more advanced system could use a scripting engine, like V8 or something (JavaScript is a very easy to learn language), using callbacks and host functions to change the display as and when necessary.
That makes little sense. If the layer for the ground is the same as the layer for the trees, how would Link be able to run behind them?
... If the layer for the ground is the same as the layer for the trees, how would Link be able to run behind them?
Interrupts. The layers can change priority even during rendering the screen (I assume).
Similar to how Mode7 works. 'Mode7' was how games like Mariokart rendered perspective, the scale of the layer was changed on the hblank, so for every scan line, the background could be a different scale, the higher up the screen, the smaller the bg, the lower down the screen the larger the bg.
I would assume that the background in Zelda, would be set behind the sprites if the player is in front of the trees or infront if the player is behind. Although I didn't know that the same layer was used for trees and grass, seems a bit silly when you have 4 layers + sprites to play with.
I knew how Mode7 worked, but to be honest I've never given SNES development much of a look. Interrupts seem like they would be glitchy: what happens, for instance, when your player is half-in and half-out?Interrupts. The layers can change priority even during rendering the screen (I assume).
Similar to how Mode7 works. 'Mode7' was how games like Mariokart rendered perspective, the scale of the layer was changed on the hblank, so for every scan line, the background could be a different scale, the higher up the screen, the smaller the bg, the lower down the screen the larger the bg.
I would assume that the background in Zelda, would be set behind the sprites if the player is in front of the trees or infront if the player is behind. Although I didn't know that the same layer was used for trees and grass, seems a bit silly when you have 4 layers + sprites to play with.
I'll take your word for it.If you dont believe me you should check it out yourself by switching on and of layers within the Snes9x emulator for PC.
I have seen many interesting funktions in layers. You should also take a look at the layers at the first stage of Donkey Kong Country 3
There is a layer there that both acts as the background and the foreground water which you can swim in. Interesting stuff is going on there and I dont know how it works.
The problem is there are LOTS of ways something can be like the Twilight Hack. It's knowing which game, where in the game and what kind of exploit it uses. There are lots and lots of combinationsthey might have known, iirc someone here said it is like twilight hack.