Try my Java SNES emulator? :)

Announce new emulators, discuss which games run best under each emulator, and much much more.

Moderator: General Mods

creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

grinvader wrote:You can bottom-up render sprites like anything else, by drawing the least prioritary of them first.

Why does having a different order of priority than the rest mean you can't handle them in the right order ?
Imagine a screen with one BG and two sprites. The priorities of the sprites are set so that sprite 1 is behind the BG and sprite 2 is in front of it. Now when you move sprite 1 around you'll see that it makes the pixels of sprite 2 disappear (showing the BG instead), even though sprite 1 is behind the BG.

That doesn't fit with the layering model. Maybe there is a way to do it strictly with bottom-up rendering, but I just don't see an easy way.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

You keep insisting on using the same hammer on screws and nails regardless and expecting things to work out. Widen your scope.
A > B > C > A (even plain A > B > A) is only an issue if you loop forever.

@byuu: oh yeah, I wasn't saying it was any efficient at all in this regard, just feasible (more than just "technically", too).
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Exophase
Hazed
Posts: 77
Joined: Mon Apr 28, 2008 10:54 pm

Post by Exophase »

spiller; You should be able to use something that's inbetween your current approach and byuu's, to get proper layering:

- Render all BG data in a linebuffer without using Z-compares per-pixel. This means doing what you're doing now (if I understand you correctly) - splitting the low priority and high priority tiles per-layer into two separate passes. In order to make this process faster you should keep a bitmask determining which tiles you should NOT draw. I recommend breaking the screen into two 32 tile regions to make this fast. Okay, really 1 32 tile region and 1 2 tile region. This way you'll be able to quickly skip entire tiles when they're the wrong priority for the second pass. If you really want to optimize it you can cache priorities and modify when the BG changes, which is relatively infrequently, but I don't think there would be a big hit anyway. As a bitmask you can quickly check to see if there are zero high priority after you've rendered, and skip the second pass entirely.

- Render all sprite data in a linebuffer without using Z-compares per-pixel. Render it in order from lowest to highest indexed sprite. Or maybe that's the other way around.

- Z-combine the two buffers. Since this is a bunch of "straight line" data you can probably optimize it to be faster than it would be embedded in the above.

You can't render + z-combine the sprites as you go because you can end up overlapping the BG with a sprite which is later masked out by a higher index sprite that's a lower priority than the BG at that pixel. This is what I refer to as "layer mangling"

There are some optimizations you can do to improve this approach.

- First, have per-scanline sprite tables that say which sprites are in which scanline - this will also reduce the amount of checking you have to do per-scanline to see which sprites to render. You can include in this data boundaries saying where sprites start and end, or perhaps keep a few regions in a small list so you know.. and update these regions as you "blit" the sprites to the list when OAM is modified. You already have sprite data caching per-OAM modification so this is a pretty logical extension.

- You can use tracked sprite regions to limit how much of the OAM render linebuffer you have to actually z-compare/copy against the BG buffer. Or if there are no sprites on the scanline you don't have to do the render pass or combine at all. Usually games will have a lot of sprite sparse lines.

- Using that list you can also track layer/sprite "coherency" - if the sprites fulfill a condition where overlapping sprites agree with priority and index relation then you don't have to worry about layer mangling. This allows you to do a faster render strategy (maybe something you're already doing?) which is:

- Render BG layer X
- Render OAM layer X (requires you to have sorted OAMs per scanline per layer) on top of BG layer X

Which involves zero z-combining.

Instead of checking something as stringent as overlapping sprites you can do stricter checks that it must pass, like checking if there's any priority/index counter-flow at all. That means, keep a max priority per index per scanline and if a sprite's priority goes below that then it could possibly mangle the scene. My suspicion is that most of the time a scanline only has one priority type on it, period.

There are some crazier things you can do to try to fix layer mangling after the fact but I wouldn't bother.

Or you could just say screw it and not emulate it at all. That's what I do with gpSP, but by GBA I don't think people were really relying on this. I do know of at least one PC-Engine game that uses it deliberately, and I do emulate it properly there.
davideo7
New Member
Posts: 7
Joined: Thu Jul 09, 2009 2:07 am

Post by davideo7 »

It's been a while since he's given any updates or replied, has he given up? If so, you willing to let someone else finish this for your spiller?
Killa B
♥ Love Freak FlonneZilla ♥
Posts: 111
Joined: Sun Apr 01, 2007 12:59 am
Location: USA
Contact:

Post by Killa B »

It's only been a month. :|
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

Killa B wrote:It's only been a month. :|
Yeah, really, these things take time to accomplish. Have patience.
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
spiller
JSNES Developer
JSNES Developer
Posts: 43
Joined: Sun Mar 15, 2009 11:09 pm
Location: Ireland

Post by spiller »

Has it been a month already? Erk!

Well I've been busy/distracted/doing other things/reading NES hardware docs/etc.

Mostly just distracted.

Keep nagging me though -- I find it very motivational.

Exophase I didn't see your post there before. Thanks very much for all the suggestions. I'll take it all into account when/if I get around to redoing the PPU.
Exophase
Hazed
Posts: 77
Joined: Mon Apr 28, 2008 10:54 pm

Post by Exophase »

spiller wrote:Has it been a month already? Erk!

Well I've been busy/distracted/doing other things/reading NES hardware docs/etc.

Mostly just distracted.

Keep nagging me though -- I find it very motivational.

Exophase I didn't see your post there before. Thanks very much for all the suggestions. I'll take it all into account when/if I get around to redoing the PPU.
No problem. If you want to talk about it more AIM/MSN/Yahoo or IRC works well for me.
davideo7
New Member
Posts: 7
Joined: Thu Jul 09, 2009 2:07 am

Post by davideo7 »

spiller wrote: Keep nagging me though -- I find it very motivational.

Was that sarcastic? :P


I know your progress came to a long stop before so just wanted to see whether that was the same case now or not (but now that you replied I know it's not the case). And of course, just trying to be supportive as I'm really excited to see what you release next.
byuu

Post by byuu »

spiller wrote:Keep nagging me though -- I find it very motivational.
Hurry the hell up! ;)

But seriously, were you able to get the OAM layering corrected with the new info? :D
spiller
JSNES Developer
JSNES Developer
Posts: 43
Joined: Sun Mar 15, 2009 11:09 pm
Location: Ireland

Post by spiller »

davideo7 wrote:Was that sarcastic? :P
It wasn't, but I've changed my mind, so it was.
byuu wrote:But seriously, were you able to get the OAM layering corrected with the new info? :D
I didn't try. The code is all too daunting, and I've been busy (lazy?) with other stuff and then I followed a tip to learn Haskell for no particular reason (some days later, Haskell turned out to be an interesting but useless programming language). "It's out when it's out", if I can borrow a quote.

Oh fine, I'll go and fire up Notepad++ :)
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

You don't have to change everything - the BG and sprite rendering code can still be used. You just have to draw them separately and combine them later...
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Exophase
Hazed
Posts: 77
Joined: Mon Apr 28, 2008 10:54 pm

Post by Exophase »

I had to use Haskell before. I don't like programming languages that are smarter than I am :<
byuu

Post by byuu »

HaskellSNES! Please? :D
Serious Callers Only
New Member
Posts: 8
Joined: Thu Apr 07, 2005 8:06 pm

Post by Serious Callers Only »

Doing a webstart is easy and very useful for testing & distribution. If you don't depend on native code and use google svn or sourceforge svn, its just a case of creating the jnlp (netbeans or eclipse preferably) setting the codebase to a place on the svn, uploading the app + dependencies + jnlp to the codebase svn url with the jnlp with the property "svn:mime-type" to "application/x-java-jnlp-file" - this makes the svn apache module set the content-type obviating the need for stupid shit like configuration files, and then link the jnlp where you want.

Example:
http://bookjar.googlecode.com/svn/BookJ ... arWeb.jnlp
haza

Post by haza »

Any chance this will be released as open source?

It has real portability potential.
paulguy
Zealot
Posts: 1076
Joined: Sat Jul 02, 2005 2:01 am
Contact:

Post by paulguy »

If not, I believe Java .class files can be considerably easily decompiled, compared to stuff like machine code.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

paulguy wrote:Image
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
byuu

Post by byuu »

Yuck, Linux interrupts. AH 09, INT 21 ftw.
diminish

Post by diminish »

grinvader wrote:cleverness
Hahaha so awesome in this context. *peals of laughter and applause*
spiller
JSNES Developer
JSNES Developer
Posts: 43
Joined: Sun Mar 15, 2009 11:09 pm
Location: Ireland

Post by spiller »

Please forgive my six month absence. After I was defeated by the SNES PPU I lost interest for a while / did other projects / had various life-mess-ups, etc. I'll spare the details (they're boring).

However, JSNES is not dead. I recently got a craving for some Java and decided to revive it.
Main changes in 0.03-alpha:
1. PPU: Many things fixed and features added.
2. Sound.
3. Many minor emulation bug fixes.

Not bumping the version number up much because it's not polished enough yet, but here it is:
jsnes-0.03.2-alpha.jar (478 kB)
*EDIT 2:* Replaced with version with working CPU debugger instead of version with insane CPU debugger that produced complete gibberish because I had some stupid idea on how to make it work better, that broke everything. Other internal improvements too.


Note: sound is currently a bit basic, limited to 32 kHz mono. It has glitches. I'll fix it another time because I'm sick of it at the moment -- I endured it fuzzing and squeaking most awfully for days -- then I tried commenting out and/or replacing a lot of the code, couldn't fix it, decided to put it all back how it was, and it suddenly worked. I still don't understand what happened. The envelope attack and release timing should be correct but the decay, sustain, and gain times/counters are definitely not. Echo, pitch modulation, and noise mode are missing.
haza wrote:Any chance this will be released as open source?
Maybe.
paulguy wrote:If not, I believe Java .class files can be considerably easily decompiled, compared to stuff like machine code.
Yes, tools like the javap command line utility in the JDK can do this.
Last edited by spiller on Wed Mar 03, 2010 1:05 am, edited 1 time in total.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Welcome back.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

Hi.. Welcome back to our forum. Beware of Wallmasters. Image
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
snkcube
Hero of Time
Posts: 2646
Joined: Fri Jul 30, 2004 2:49 am
Location: In front of the monitor
Contact:

Post by snkcube »

Great job with the sound. It's coming along nicely.
Try out CCleaner and other free software at Piriform
Image
spiller
JSNES Developer
JSNES Developer
Posts: 43
Joined: Sun Mar 15, 2009 11:09 pm
Location: Ireland

Post by spiller »

Thanks. Doesn't seem to be much interest though. :( Is there somewhere else on the intertubes I should be posting this to get more people to offer feedback? I'm not up on the emulator "scene" I'm afraid, and the ZSNES forum is the first and only place I've posted it.
Post Reply