bsnes v0.040 released

Dullaron · Post by **Dullaron** » Tue Mar 10, 2009 2:33 am

Edit: Sorry about that. I trying to see what I'm doing wrong.

That fix didn't solve the problem though. Just would not make right on QT end. It for the older version I think.

gllt · Post by **gllt** » Tue Mar 10, 2009 2:47 am

http://img14.imageshack.us/img14/6584/wooden2.png
http://img12.imageshack.us/img12/2526/test1c.png
http://img18.imageshack.us/img18/6099/testrok.png
and a couple more, now I'm gonna go look at some real border designs and wait for the style thread

edit; another http://img9.imageshack.us/img9/3152/wooden3.png
scale3x. much nicer idea there.

Dullaron · Post by **Dullaron** » Tue Mar 10, 2009 4:40 am

I gave up on Qt. Too many issues on make. Might not work on my Vista.

I have seen other people having some issues at their forum as well. Look like I'm not only person having issues.

I uninstall Qt and MinGW. Least TDM/MinGW works on the older bsnes src.

FitzRoy · Post by **FitzRoy** » Tue Mar 10, 2009 4:48 am

How about making the controller images external options as well? In other words, bsnes could make the paths to the images selectable somewhere for all controllers. There, no wasted bandwidth and people can display whatever the heck they want or nothing at all.

"but, but, the button order..."

"but, but, the searchable internet from which you downloaded the program..."

Let's call a spade a spade, this is a frills option that has nothing to do with user-friendliness. Other emulators have done without images for a decade.

byuu · Post by **byuu** » Tue Mar 10, 2009 12:08 pm

I'm about ready to just ask byuu to pull the image. This has become a "you're an idiot because you don't know about alpha channels" thing directed at me.

If you want it removed I'll respect that, but I was honestly hoping to not have to worry about that sort of thing.

I'm sorry you're getting hassled over this. But it's the internet; no matter what you do or how much work you put into it, people will complain about it. For what it's worth, I think it's amazing; and the amount of time you put into it has just been incredible.

Remember, this is what I came up with before FitzRoy and you:

( hey, at least it was only 13kb :P )

And this was the leading competition from Snes9X prior:

How about making the controller images external options as well?

Might be possible, not sure. Want a fallback to something.

Meh. About logo that's too flat, image controller graphic that's too big on low-res monitors, all kinds of hell getting a new hard drive in, an unstable system that locks up arbitrarily, bandwidth issues and no idea how I'm going to distribute WIP releases now, being about six months behind in ROM hacking work ... anxiety is getting to be a bit much.

Think I'll mess around with Qt 4.5 a bit more, sinamas gave some helpful info on how to make it smaller. And if I can figure out how to get JPEG support into the static builds, we can drop the controller down to ~30kb with no visual quality loss.

Other emulators have done without images for a decade.

And are their UIs as nice / user-friendly? :P
I wouldn't be surprised if more time was spent on the UI than emulation itself at this point. Mostly my fault, this is the fourth entire UI-rewrite in four years.

But ... hopefully the last. This even gives me native 64-bit Cocoa support, so we just need a Mac person to create the build rules and the source should work on all major operating systems.

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 12:26 pm

Ah don't worry about it, byuu. I just get pissed off sometimes and want to get away from it all. I've seen that happen to you as well

Anyway, If you're still interested in a getting a smaller version of the graphic, I'll go ahead and render one. I need to anyway as the current verion you have is outdated. The current version has a very minor fix that my OCD had to take care of on the button face.

I'll post the 420 version you wanted here in in this thread. brb in a little while.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Tue Mar 10, 2009 12:29 pm

So you just didn't know about alpha channels, that's fair enough. It's not exactly obvious. The tutorials were a bit much, and I can understand taking the P.NET comment as an insult when you've already shown your skill at using 3dsMax (which I can't even do the first thing in.. that program is insane), so I hope this whole thing can just blow over and we can move on and use your awesome graphic

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 12:43 pm

Weird. I keep getting some sort of active X warning every time I open this thread...

Anyway, I made a 420 version for byuu with the latest model in case he wants to go smaller. The image is only about 75kb too:

(image deleted)

As I told byuu, my only problem with using such a small version is all my bump-mapping work becomes invisible. Its really no big deal though, because I always have the bigger one for desktop wallpaper. Speaking of which, I have a 1680 version on my desktop now

gllt · Post by **gllt** » Tue Mar 10, 2009 12:46 pm

Any chance of a height of 512 width of matching aspect ratio version with cord/no-cord on transparent for high quality icon use?

tetsuo55 · Post by **tetsuo55** » Tue Mar 10, 2009 12:50 pm

byuu wrote:
Regarding NHL 94, I actually remember that game's title screen being hclock sensitive. However, I thought your recent scanline improvements solved that.
NHL '94, Jurassic Park, Battle Blaze, Dai Kaijuu Monogatari II et al are sensitive to ppu.hack.render_scanline_position. We use 512, NHL '94 works fine at 1024.

What I did was remove ppu.hack.oam_cache, which affected Adv of Dr Franken, LoTR, Megalomania, Nightwarriors and Winter Olympics.

Essentially, the OAM cache fix was making a single register ($2101 / OBSEL) "sort-of" cycle-accurate (we don't have the exact cycle it's read pinned down, I just guessed until everything worked). In NHL '94's case, it's the same issue with the game writing registers mid-scanline, but with a different register (probably BG enable or one of the mode 7 regs.)

I don't want to keep extending the scanline-PPU in this manner, and it won't really work as some of these regs are probably read at varying times (and even multiple times) per scanline. I know the BG enable reg can be written and take effect almost immediately -- the PPU reads it repeatedly every few cycles, which is 100% incompatible with my renderer, hacks or not.

And you saw the speedhit from the OBSEL workaround already ...

Would something like this:
http://gendev.spritesmind.net/forum/vie ... highlight=

Help improve the current PPU code to the point of 0 known bugs?

The person who posted that has an oscilloscope to measure all kinds of video timings.

I would guess it could be used to find the correct hclock positions for those games mentioned. Also we could find all the timing differences between NTSC/PAL(at least for the version of the snes he has\we send AND assuming he is snes friendly and wants to help)

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 12:51 pm

gllt wrote:Any chance of a height of 512 width of matching aspect ratio version with cord/no-cord on transparent for high quality icon use?

I'll have to actually learn how to do the whole alpha channel rendering thing, but I'll give it a try. 3DS Max does support PNG output with alpha channels, and the above render is just a straight 32-bit color png output file from the program.

gllt · Post by **gllt** » Tue Mar 10, 2009 12:55 pm

I figured it was in the rendering window, at least I thought it was.
But technically one could be forged for it in photoshop/psp over a current render

edit; open the render window, render, and then press display alpha channel and save
I think that will do the trick :B

FitzRoy · Post by **FitzRoy** » Tue Mar 10, 2009 1:25 pm

byuu wrote:And this was the leading competition from Snes9X prior:

Whoa, that's retro.

Might be possible, not sure. Want a fallback to something.

As long as you can use nothing like your fullscreen frames, I don't really care what comes with the exe.

byuu · Post by **byuu** » Tue Mar 10, 2009 1:32 pm

I just get pissed off sometimes and want to get away from it all. I've seen that happen to you as well

Oh yeah, all the time. And I really should, I'm just too persistent for my own good / health.

Spent two weeks to figure out that IRQ triggers on two-cycle read+IO opcodes convert the IO to another read. Doesn't affect anything, but damned if I was going to walk away without my answer.

As I told byuu, my only problem with using such a small version is all my bump-mapping work becomes invisible.

Hmm, that it does. It crushes the 'entertainment system' text as well, as you said. But that's so much more manageable for the window size.

Going to think about an alternative layout instead of those 'assign mouse' buttons, so we'll see how it goes.

Thanks a bunch for the smaller version :D

Help improve the current PPU code to the point of 0 known bugs?

No, sadly. It's hard to call these things bugs like the recent OAM y-overflow issue. The rendering itself is computed correctly, it's just not synchronized frequently enough. It's the entire model of emulation that's flawed.

Okay, say a game draws 256 pixels per scanline for 256x224. The game can turn the display on or off at any point: if it turns off the display at pixel 128, then only the first half will be visible; if it does so at 192, only the last quarter will be invisible.

With our current approach, we pick ppu.hack.render_scanline_position (which is 512 / 4 - ~22 from the real pixel offset) to tell us exactly where to render. The emulator treats it like the register values never change for the entire scanline, it takes the values that are currently there at exactly one point and ignores the other ~340-680 sample points.

The renderer is deeply tied to the idea of doing everything video-wise at one exact point: it computes the mask tables, it performs OAM range-time over, it draws each background layer, and finally blends everything together. The entire thing would need to be split to only process a pixel at a time and return control to the CPU for a little bit to get the PPU 'bug' free.

OBSEL's caching was more of an exception than the rule. Who knows, it may even get read more than once a scanline, but no game relies on that behavior.

As long as you can use nothing like your fullscreen frames, I don't really care what comes with the exe.

Hmm ... shouldn't be too hard. Just need to give the art box an ID and we can kill it with negative margins.

tetsuo55 · Post by **tetsuo55** » Tue Mar 10, 2009 1:43 pm

Could the oscilloscope help accuracy in any other way? or do we have 100% accuracy for the things it would reveal already?(for both PAL and NTSC)

byuu · Post by **byuu** » Tue Mar 10, 2009 1:49 pm

Oscilloscope readings are too analog, I can't make any sense out of them.

What I would really like is someone to take the two PPU chips out, solder them to a custom board, and let me use my own clock chip that is massively slower and allows me to poll all of the PPU's pins (especially address + data lines) at any given cycle to see what it's trying to do.

Being able to control this all from software on the PC would make things 100x easier for me to work out the algorithms involved.

Short of that, I'll have to use my cycle timing libs to send writes at every possible pixel position.

Much easier to determine where OAM writes go, since I can digitally read that back. Much harder for analog like the final video output.

tetsuo55 · Post by **tetsuo55** » Tue Mar 10, 2009 1:53 pm

I see, it helps the genesis because its not all digital.

I think there actually are people capable of doing that, but they would have to be emu friendly and it would probably cost a lot.

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 1:57 pm

Ok I learned some basic use of alpha channel rendering in 3DS Max, but I could not figure out how to get it to exclude the cord from the alpha channel. It doesn't seem to have an option for that because objects cast shadows and so it doesn't know how to interpret the masking for the shadowed area. Anyway, below are 512 versions, first one is with cord and 2nd is without. BOTH versions have the alpha channel mask intact:

Keep in mind the alpha channel blending is based on a white background. It will look shitty on dark themes.

(images deleted)

DancemasterGlenn · Post by **DancemasterGlenn** » Tue Mar 10, 2009 2:15 pm

Those look awesome!

Lazarus · Post by **Lazarus** » Tue Mar 10, 2009 2:24 pm

Byuu, repository.cinnamonpirate.com doesn't seem to have been updated since bsnes v0.034. Is it dead?

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Tue Mar 10, 2009 2:25 pm

You're right, they do look worse on a dark theme. I don't really understand why, because what does transparency have to do with the background? Unless it's just something that's needed to render it. Would using a grey background (0x808080) look worse on light themes? Also, what if you rendered it at a higher resolution, made the surroundings transparent, then scaled it down? That should minimize the effect of blending with the background.

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 2:37 pm

Its the antialiasing effect. If you render the alpha channel without it, the image becomes horribly blocky around the masked edge. Its sort of the give-and-take. You can either have a blocky edge that will blend with any background color, or have a smoothly sampled edge that requires a background specific color to look good.

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 2:49 pm

Here are the same versions with black background masking:

(images deleted)

byuu should be able to find something of use from all these versions

Jipcy · Post by **Jipcy** » Tue Mar 10, 2009 4:27 pm

All four examples look excellent with the transparent background.

I noticed on the ones that blend with the black background, that the bottom edge of the controller looks fine, but the top edge (around the shoulder buttons) has a black outline. Whereas with the white background blended images, there is a white outline all the way around. Is there any way to not blend the edges at all? Or blend them with a transparent background?

Also, for the final version to be included in bsnes, you should maybe crop the image to be tight to the controller and/or change the rendered output size. And also run multiple PNG optimizers on it to get the lowest file size.

FirebrandX · Post by **FirebrandX** » Tue Mar 10, 2009 4:36 pm

Jipcy wrote: Or blend them with a transparent background?

I had to giggle a little bit over that. You can't blend something that doesn't exist. What you're really asking is if I can remove the antialiasing. As I stated, you end up with a horribly blocky edge when you do that.

The closest compromise I can give you is a gradiant background blend that goes from light to dark. This way, the top portion would not have a dark edge, and the bottom portion would not have a light edge. Actually that may be the best mothod come to think of it. I'll post 2 new ones with that method shortly.