, but if bubble2k16 modify it, it would be AWESOME, really.
Still opaque, unfortunately.I'm in the office, and I forgot my console, but can someone tell me if it's already solved the problem of transparency of some sprites like the water layer in Kirby Dreamland 3?
I'm in the office, and I forgot my console, but can someone tell me if it's already solved the problem of transparency of some sprites like the water layer in Kirby Dreamland 3?
To achieve transparency effects in Dreamland 3, some basic hi-res mode workaround would be needed.
Thank you!^I Think that GBA VC is not emulated, it's simulated in the ARM9 core, so it's pretty much like running in a GBA, at cost of savestate, graphical improvements and etc.., but for that accuracy, i think it's a pretty good trade
1-4 has the water soon into the level, and the first part has foreground elements. I'll try and get a save state for you if you still want it.
It took many years for Snes9x to reach version 1.43 with close to full compatibility, and more to reach version 1.5+. But if you want to try, for a start, it's a good idea to take a look at source codes for the emulator for simpler machines, like NES, or Atari and see how they work.
mGBA is most accurate right now.
That's because it's not really being emulated but rather runs natively with the AGB_FIRM as far as I know.
Wow, it's an in-depth topic. The basics of cycle counting is that you will need to know how many clock cycles each CPU opcode takes to execute. Referring to the CPU's actual documentation will tell you that. So every time you emulate them, you have the add the clock cycles to a counter. From there you determine when to fire your interrupts. And once you run enough cycles (based on the MHz clock speed of the processor), you will know that when it's time to draw your frame.
The actual ROM program (the one you emulate) instructs the sound/graphics/other hardware by either sending software service commands or by writing to specific locations in memory. From there your emulator reacts accordingly by updating the state of the emulated graphics hardware, or performs some action. Like in SNES, writing to certain registers in memory triggers a data transfer to the graphic's Video RAM. Then, when it's time to draw your frame, you simply render to the screen based on the current state of the emulated graphics hardware, and all the bitmaps / textures supplied by the game.
The same idea applies to sound with a few exceptions - sound has to be generated fast enough so that it can be continuous, otherwise the player will hear clicks, pops or other horrible artifacts.
And save states? You basically take current hardware state (CPU registers, current clock cycle, graphics registers, sound hardware registers, memory, and everything that can change and affect emulation) and save it to storage. Then load it up again later to continue the emulator for where it was previously.
That's the general idea, but the devil is in all the details, and it can get quite crazy, because the console hardware (both graphics, sound and CPU) may have some bugs itself, and sometimes your emulator has to emulate these bugs for it to work correctly for some games. It's a tough job.
Depending on what console you want to emulate, you have to really understand the hardware very very well. The internet is your friend here. For my SNES needs, I go to http://wiki.superfamicom.org/snes/show/65816+Reference (and of course the source code for Snes9x v1.43 was the primary source) You have to look for yours.
--------------------- MERGED ---------------------------
Oh ok, I stopped at 1-3. I'll go back and try tonight. Thanks!
Why don't I have those translucent issses? I'm using the v1.00 CIA. The leaves in level 1-1 are solid for me.@bubble2k16 You needn't go as far as 1-4 at all.
The first use of high-res occurs on 1-1, after entering this door:
Which leads to this room, with hi-res "translucent" floating leaves:
For something very slightly easier to see, you might try 1-2, with "translucent" foreground bushes (?) at the very start of the level.
Haha. That is the issue, they're supposed to be translucent. Later on in the game, these sorts of things will obscure the gameplay more and more to the point where you won't be able to play like that at all. On a real SNES, the hi-res mode is used to output all the see-through stuff in the streaky way you see in those screenshots. But TVs of the day wouldn't be providing the sort of sharp, pixel-perfect images you see in these screenshots, so the result of the simple analog "filtering" was that on screen it would just look like normal translucency. The idea now is that any emulator playing Kirby's Dream Land 3 really needs to do that filtering that used to just be a side effect of composite video and CRT TVs.
Ohhhhh! Gotcha. It's been a while since I've played that game so forgot it was supposed to be translucent.
For Satellaview games use blargSNES VC injections. I think he already mentioned there wasn't anything planned to further compatibility for Satellaview games as it would be too difficult.
Nintendo saying O3DS can't do SNES emulation isn't entirely a lie. Their VC emulator is entirely software based. O3DS couldn't do SNES emulation without hacks and entirely in software.
Ok. Well i think both snes9x and blargsnes use hardware rendering. Can you tell me the difference between them
@
K3Nv2:
@
K3Nv2:
