Pages: 1 2 3
Near
Burned-out Genius Developer
Post: #21 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Pretty much the last major feature I've wanted for years but still can't pull off is DRC.

Thanks to BearOso's code, I was able to manage this for OSS on FreeBSD. But that's a pretty niche OS. I'd really like to get this into bsnes on Windows.

I attempted the same with XAudio2, but it failed:
https://gitlab.com/higan/higan/blob/master/ruby/audio/xaudio2.cpp#L55

Talarubi gave debugging it hir all, but it would appear that the issue is XAudio2 has a minimum buffer size that is too large, and requesting a smaller size just gives you a larger buffer anyway. I don't know how to square that away with Snes9X purportedly supporting DRC with XAudio2, but maybe it's due to emulation core differences.

I saw that Snes9X recently implemented DRC through waveOut to avoid the limitations of DirectSound and DRC, so I tried the same:
https://gitlab.com/higan/higan/blob/master/ruby/audio/waveout.cpp

But unfortunately, I'm at a loss as to how Snes9X is implementing its DRC through their driver. Specifically, I'm not sure how to create the required level() function in the waveOut driver.

With any luck, it'll only be five or six lines of code. Would anyone with some spare time be up for lending a hand with this?
Near
Burned-out Genius Developer
Post: #22 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Oh no, my naming choice came back to bite me.

I should have named the functions available() or remaining() to avoid inverting what they return and not realizing it.

Thank you so, so much! ^-^ I will test this out and report back.
Near
Burned-out Genius Developer
Post: #23 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
It turns out I can't test XAudio 2.1 because it's just not available on Windows 10.

But for waveOut, I had to patch the processing code around a bit, and increase the buffer count, but ...... it works!! :D

Hooray, thank you so much!!
Near
Posted on 19-04-10, 18:22 in Announcing the bsnes history kit
Burned-out Genius Developer
Post: #24 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
I also received a bundle with manual disassembly of many of the test ROMs, but unfortunately I seem to have misplaced it during the move to Japan ... sigh.

I'm really not very well organized.
Near
Burned-out Genius Developer
Post: #25 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Speculative emulation with rewind for misses is how Nemesis' Exodus emulator for the Sega Genesis works. It still needs equivalent processing power as higan does for the SNES, only now there's also an extremely complicated layer to rewind the emulation core present for no real gain.

It's possible a better implementation of speculative emulation is possible that would result in more impressive speeds. But even if there is, I don't think there's a huge market for it.

Sour will probably produce something rivaling bsnes' accuracy at more reasonable speeds already. And even if that doesn't pan out for some reason, I really think we have our bases covered well with Snes9X < bsnes/fast < higan.
Near
Posted on 19-04-11, 04:40 in Announcing the bsnes history kit
Burned-out Genius Developer
Post: #26 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Here's a useful discussion / test ROM if we're going to try and build a collection of emulator test ROMs:

https://forums.nesdev.com/viewtopic.php?f=12&t=16330
Near
Posted on 19-04-11, 04:42 in What makes speculative execution in emulators impossible? (revision 1)
Burned-out Genius Developer
Post: #27 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Yes, that's correct.

Although to be fair, Nemesis does take abstraction a lot further than I do.

For instance, each CPU instruction has its own class.

It's definitely cool if you wanna really focus on just one CPU instruction, but I mean ... yeah. It's possible that the rollback implementation is not as fast as it could possibly be.
Near
Burned-out Genius Developer
Post: #28 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
I specifically want to maintain Windows 7 support.

I realize its days are numbered, but a lot of people (including myself) dislike Windows 10.

If we can offer 2.1 and 2.8 simultaneously, with 2.8 simply not being available on 7, that could work.

Then again, waveOut, DirectSound, and XAudio2 all use the same backend anyway. There's not really a lot of point to using XAudio when waveOut is perfectly fine.

Microsoft, like me, just likes to keep reinventing things constantly.
Near
Posted on 19-04-15, 01:32 in Emulation and arbitrarily sized ROMs (revision 1)
Burned-out Genius Developer
Post: #29 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
> He just expands it to whatever oddball size it comes out. (say like Final Fight, but with say 150 bytes added on)

Most images from the SNES copier / early demoscene era were like this, which is why bsnes can load these images. Although few will run properly because I don't also zero-fill RAM like old copiers did, and most of those games also don't initialize RAM or registers first. But I do intend to offer a compatibility mode at some point.

> "sorry SNES9x sucks use higan"

Now there's a statement I never thought I'd hear >_>

> But I wonder if you know, just how bad the potential for out-of-bounds errors with incomplete ROM banks. I would guess the rest of CPU space is just random garbage?

higan uses a function (hat tip to Nach for the idea) to presume any arbitrary file is comprised of increasingly smaller ROM chips, that are all powers of two, and then mirrors them up from there.

So say you had an 11mbit game: 0123456789a----- You could say this is an 8mbit + 2mbit + 1mbit cart. So keep doubling the size of the smallest ROM until it fills the space. So 1mbit->2mbit of a = a a. So then we have 0123456789aa----. Now it's as if we have an 8mbit + 4mbit game. Do the same thing again, 4mbit->8mbit. 89aa 89aa. So the result is 0123456789aa89aa. If you had a 9mbit game, it'd be 0123456788888888. You go until the ROM size is a power of two.

If you have a real ROM chip, it may not truly be a power of two. There are single-ROM chip games on the SNES that are actually 24mbit. The datasheets list them as 3072kbit chips. But from an electronics perspective, there will be a set number of pins. And the total addressable values will always be 1 << address lines. Or 2^address lines. The ROM chips themselves simply ignore the second-most address bit when the highest address bit is set. So it's the same as with the algorithm above.

This actually would be a problem if people made RAM chips this way: writing to one address would modify two readable locations. But in the 25 systems I support, I've yet to encounter a RAM, EEPROM, or Flash chip that wasn't a power of two. I know they exist however.

> I thought I should ask the principle to you, byuu, the one who defines Spectre as a 7mbit game? Is there any reason it shouldn't be 6.98731 mbit or whatever the used data comes out to? :)

I can't tell the difference between the same game released as 1x 32mbit with 8mbit mirrored, 1x actually a true 24mbit chip, and 1x 16mbit + 1x 8mbit boards. And when you run my algorithm above, it produces the same file either way. So ***it doesn't matter at all***. My PCB scans show you the ROM chips, and if they have part#s, you can try to confirm it. But a lot of the later Majesco 1x 32mbit boards do not.

You all know how incredibly obsessive my interest is with the SNES and getting everything absolutely perfect. You all know why I'm like that. And if I'm telling you it doesn't matter, then ... maybe trust me on that one :P

Absolutely everyone who ever maintained a ROM database agrees that a 24mbit game is 24mbit, and that 32mbit with 8mbit mirrored is an overdump.

The reason my Spectre dump is 7mbit is because the tool I wrote to remove overdumping stops at a 1mbit boundary. I chose 1mbit because it's the smallest whole number in SNES unit sizes (every SNES game is referred to in megabits.) That's all. It was completely arbitrary, and it bothers me a bit that my decision resulted in confusion like this:
https://datomatic.no-intro.org/index.php?page=show_record&s=49&n=3336
"Overdumped according currently ROM hash information from byuu"

I don't know what the community consensus was, but in hindsight it sounds like most people think 4mbit (0.5MiB) is the gold standard?

But you're right, it's arbitrary. If the very last two bytes were repeated, you could cut just one of them off if you stopped at the byte boundary.

I really don't care, and I would be very happy if I never had to address this topic again :P

> No, it's not sane. You'd need to expand to something like 32k boundaries at least

You're going to hate my Devil's Advocate here, but ... you could make a 2k SNES game. In fact, I have one. blargg modified a sports game cart to map RAM in place of ROM for me, and I used that as a devcart to launch my USART serial loader prior to the 21fx by defparam. The 2k would just be mirrored to fill 8000-ffff, so if you only have 0000-1fff, then your vectors would go at 1fxx. There is nothing preventing a 1-byte SNES ROM, other than it not being terribly useful. 21fx is 124 bytes and is obscenely useful to me.

In practice, the smallest licensed SNES game I know of is 256k for Space Invaders. Some of the Nintendo Power releases were very odd sizes like 5mbit and padded with FF bytes.

Lastly, I'll just add that since it doesn't seem likely SNES9x will ever support DSP LLE, you might want to consider how appended coprocessor firmware behaves in SNES9x, for the six people in the world who agreed with me on that one who may try running those games in SNES9x. They work according to my own testing, but if you change how things mirror, then I don't know. Just mentioning it, you're free to handle this however you like, or not at all.
Near
Posted on 19-04-15, 10:59 in Emulation and arbitrarily sized ROMs
Burned-out Genius Developer
Post: #30 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
> I figured there might be a counterexample, but I stand by my statement: that’s still insane.

There's nothing folks on the internet do better than "well, actually..."

We should make sure every child has food. Internet: "well, actually..."
We should research cures for deadly diseases. Internet: "well, what about..."

I'm not above it, apparently :P

But yes, it's completely insane. If you're willing to reject the ROMs, I'd be willing to consider doing the same in higan.
Near
Posted on 19-04-15, 19:44 in Emulation and arbitrarily sized ROMs
Burned-out Genius Developer
Post: #31 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
> You're winning! Another decade or two and you may be number one!

I have a strong feeling neither bsnes nor Snes9X will be in the top spot in a decade. We'll see.

> There's a 1K block reserved for the scratchpad RAM, but they only installed 256 bytes because SRAMs were expensive, and the same quarter-K is readable and writable at all four "slots" in the reserved address block.

That's easy mode, it's still a power of two so you just mask the address. But if it's 3072 bytes in a 4096 byte space, you have a real problem. Not even a painful modulo will work because that'll make 0xc00=0x000 instead of 0xc00=0x800.

If it's part of the system you can hard-code this in a lot of ways. But when it's a cartridge, it will be very annoying to support. higan/bsnes' SNES mapping code can do it because it's byte-level, but that's the most heavy-handed solution possible for the problem.

> The DSP firmware is 8k, so it would have been mapped and not truncated even with the prior behavior, so I don't think it's going to break anything except the checksum.

I have code to detect all of the firmware files being appended. I have a rule that copier headers and firmware aren't compatible, so that gives us:

https://gitlab.com/higan/higan/blob/master/icarus/heuristics/super-famicom.cpp#L412

  if((size() &  0x7fff) ==   0x200) return removeCopierHeader();
  if((size() &  0x7fff) ==   0x100) return size() -   0x100;  //Super Game Boy 1&2
  if((size() &  0x7fff) ==   0xc00) return size() -   0xc00;  //Cx4
  if((size() &  0x7fff) ==  0x2000) return size() -  0x2000;  //DSP-1,1B,2,3,4
  if((size() &  0xffff) ==  0xd000) return size() -  0xd000;  //ST010 & ST011
  if((size() & 0x3ffff) == 0x28000) return size() - 0x28000;  //ST018


Well anyway, it's not important. It failed to get any kind of adoption and I gave up so much on trying that I just re-added DSP HLE support instead.
Near
Posted on 19-04-16, 20:51 in SNES HD mode 7 (revision 3)
Burned-out Genius Developer
Post: #32 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Okay so this absolutely blew up last night.

https://www.reddit.com/r/emulation/comments/bdltmo/hd_mode_7_mod_for_bsnes_v1071_beta_1/
https://www.resetera.com/threads/bsnes-emulator-mod-allows-for-hd-rendering-of-mode7-games.111715/
https://www.pcgamer.com/this-snes-emulator-mod-makes-mode-7-graphics-hd-with-amazing-results

I implemented hires mode 7 in bsnes, where I render at double resolution, which is the same thing ZSNES and Snes9X used to do. It didn't make a large difference, so I just filed it as a novelty option and moved on. u/DerKoun on Reddit came along and upped it to 16x resolution for jaw-dropping results:





Frankly, I'm stunned we didn't realize this level of detail was possible for 20+ years.

So, I intend to offer this in bsnes, but I'm curious if Snes9X and/or Mesen-S are going to be interested or not.
I know Snes9X recently removed the feature, so ... maybe it's too soon?
But if others want to implement this, I think we should coordinate on what we name all of the various options and how they work, mathematically, so we can provide a consistent user experience instead of a mass of confusion. I won't hold back anyone's progress: if someone comes up with something cool, I'll implement it as well.


Current considerations:

* supersampling: if we scale the resulting image back down, it makes the pixel resolution match better without causing too great a disparity between sprite pixel sites and the background detail. Example: https://i.imgur.com/DTBoOTN.gif
* prescaling: we can perform filtering like HQ2x onto the mode 7 background first to smooth the jaggedness of the output, but that probably won't matter unless we go crazy and output at 4K mode.
* interpolation: we can interpolate on the output pixels to smooth things out, and also introduce more than 256 colors from the source image in doing so.
* maximum scaling factor: do we stop at 1024x1024, or go up even higher?
* perspective correction: affine texture mapping (eg what mode 7 actually is) has a really obvious problem with distortion. We could offer an option to correct for this. Example: https://en.wikipedia.org/wiki/Texture_mapping#/media/File:Perspective_correct_texture_mapping.jpg

If no one's interested in coming up with some standard terms and features for this, that's okay too, and I'll just experiment on my own for now.
Near
Posted on 19-04-17, 00:55 in SNES HD mode 7
Burned-out Genius Developer
Post: #33 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Yeah I wanted both BearOso and Sour to see it, and they're on different boards generally, so ... why not.

> HQx/xBR would be great, but it doesn't store the texture as one big image, does it?

It is one big tilemap, 1024x1024. The complication against just throwing it into OpenGL (yuck) is that it doesn't work like a standard affine texture mapping where you just give 2D vertexes for all four corners to get your output image, the SNES games update the mode 7 parameters on every scanline during HDMA.

When it comes to my own hires, all I'm doing is giving twice the fractional bits to run along the horizontal axis. Since the screen is 256x240, the result is you pull more underlying detail out.

But say you're really zoomed in and only viewing a small portion of the screen, now the smaller portion has to be stretched to fill the screen, and at this point, HQ2x would be beneficial in the same way mip-mapping is. At least in theory.
Near
Posted on 19-04-17, 03:25 in SNES HD mode 7 (revision 1)
Burned-out Genius Developer
Post: #34 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
> "Optimize for 3D perspective", and people suggest that it's actually an option from base bsnes

Yeah I don't know what that's about, it's not an official bsnes feature.

> For one, it’s not using triangles, so you’re not interpolating on two separate primitives.

Ooooooooh, I get it now. Sorry. My mind's a bit muddled from trying to emulate 25+ systems and not touching this code for a while. Embarrassing >_>

> HQx would need to have tile adjacency information when sampling

The idea in my mind was, you have a 128x128 tilemap, so you fuse the whole tilemap together into one big 1024x1024 image. Then you can HQ2x that. Then if the screen is zoomed in on a smaller portion of it, it should help remove some of the remaining jaggedness we're seeing.

I am aware that "HQ2x a 1024x1024 image" is going to be one hell of a demanding operation, so I don't expect this to work on games that update the tilemap often. It'd probably even cause FPS dips doing it a single time even with OpenMP.

I also expect this approach to fall on its ass for any mode 7 scene that isn't literally just a simple rotozoomed quad (eg Hyperzone.)

But maybe the entire idea is nonsense.

> The hardest part now is just dealing with the higher resolution layer in combination with the other ones.

I also haven't looked at the code yet, but my thought was to have an entirely separate PPU renderer for HD mode 7, that would gut features like EXTBG and interlace that aren't used in mode 7 by licensed games anyway. It would also lack BG rendering, so now you just have the mode 7 layer, sprites, windows, and color math to worry about. It's not gonna be fun, of course. But the results are breathtaking enough (especially Dragon Quest 3, good lord) to warrant the work, probably. We'll see.

I need to undertand what his 3D perspective setting does now.
Near
Posted on 19-04-17, 14:14 in SNES HD mode 7 (revision 3)
Burned-out Genius Developer
Post: #35 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Geez, I am really getting all of the details wrong on this. It's been too long, too many systems since I implemented all of this.

Okay yeah, so they're using EXTBG mode to get the priority bit. I was thinking of the mosaic 'glitch' where you can reveal very obvious and extreme differences between BG1 and BG2. So what I need to do is drop the ability to use both BGs at the same time, and instead just render one layer. Interlacing can definitely go, at least.

But yeah, I am still going to need an entirely separate mode 7 PPU renderer, so that the upscaling support of sprites and windows doesn't affect performance when not in use. Then again, if any games do a mode 7 - > mode N change mid-scanline for eg a text box, then I am screwed.

> Hyperzone only changes the color palette

Again, I'm an idiot >_>

Yeah, the idea to upscale the underlying 1024x1024 screen won't work if the game changes the palette every frame.

Well, there's probably something we can do with the interpolation besides nearest-neighbor that won't be too costly. Maybe a simple scale2x would work. It works amazingly well on certain patterns, like the bottom bar in Super Mario Bros. 3 (All-Stars.)

> If you want to interpolate HD scanlines between two SNES scanlines, you need to know the configuration the game used for the upper and lower SNES scanlines to do the interpolation. However, that would require letting SNES emulation advance to the next scanline before you've drawn the previous one, and that might have implications for sprite rendering, etc.

Oh boy, if that's the case then I sure lucked out with making the multi-threaded PPU recently. It caches all the screen stuff (registers, palette, etc) each scanline so you can draw everything at the end of the frame at once.

There is a limitation where this will get split into batches if a game turns the screen off mid-scanline for VRAM writes, but in practice there isn't a game that does this. They'll turn it off at the top or bottom edges to get more Vblank time, of course, and that doesn't matter, the end result is the flush() call still has an entire frame worth of scanlines at once.

However, that's bad news for getting this support into Snes9X and Mesen-S. They'd have to also adapt a line caching system like this. Gonna go out on a limb and guess Snes9X won't want to use my PPU core, nor do I really want to license that one to be usable in closed source forks ... tricky.
Near
Posted on 19-04-18, 07:11 in SNES HD mode 7 (revision 1)
Burned-out Genius Developer
Post: #36 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
I implemented DerKoun's work, and I understand it now.

By default it just interpolates between two real scanlines nearest to the virtual scanline being output.

The perspective option instead scans up and down the frame to find the first and last mode 7 scanline, and takes the matrix transform parameters from there. So yeah, HDMA effects that do something other than a standard affine-style transformation won't work, but most games do that so it's usually fine.

I think the perspective option can be enhanced in the future to detect when a frame isn't really in perspective, and to disable the option for said frames. Could even design it to split the frame into multiple chunks, so eg Terranigma can be made to look good. Probably won't be trivial, though. Certainly it's above my head, mathematically.

Also, upon implementing this, I can see that unfortunately this will be a nightmare for other emulators to implement, especially for FPGAs.

The only reason this is possible is because of my new parallel PPU renderer that builds up an entire frame worth of scanlines (I/O registers and palette RAM.) If you don't implement this, you won't be able to do the critically important perspective correction. You can probably manage the non-perspective variant by averaging between the current and previous scanline mode 7 parameters, though. Then it's just a matter of some gruesome code to scale up mixed-mode backgrounds and sprites to your larger canvas.
Near
Posted on 19-04-19, 23:19 in SNES HD mode 7 (revision 1)
Burned-out Genius Developer
Post: #37 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
On the track-select screen, I can switch between resolutions and toggle "Perspective correction" with impunity. Once I reach the actual time trial, I can still switch resolutions but the moment I touch "toggle perspective", boom!


Very strange. I'll look into it, thanks.

with DerKoun's beta 3 in Mario Kart the internal resolution (if that makes sense) is now different on the track than it is on the title screen and menus.


That one was my change. It's the same way hires and interlace modes work, the output resolution is the smallest size that will fit the game content. This is a fairly important speedup (outputting 4K pixels in *software* is going to be intensely painful even without any emulation at all), and it's also necessary to output at 256x240 for most shaders to work.

It does look bad when changing modes, but the alternative is relegating 90% of hunterk's quark shader repository to non-working status.

If we were willing to kill all but the OpenGL driver (which lacks exclusive mode support), I could include an option to upscale the video to a set size using point sampling, then apply shaders to output the final image. Shaders themselves could also be updated to be given hints as to the underlying resolution as well, but every single one would have to be updated.

Ugh. I went back to look at the bilinear filtering, and it's just not good. I won't be doing that.


Ah, darn =(

Well, this is just a gimmick after all. It also can't really work with mode 7 mosaic by design, and the 3D perspective correction option is hit-or-miss depending on the game. Makes for some amazing screenshots, though.
Near
Burned-out Genius Developer
Post: #38 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
Anyone want to place bets on the next Xbox console name?

I'm going with Xbox zero,7 (European-style point)
Near
Burned-out Genius Developer
Post: #39 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
I've got it. The new name will be the Xbox 360 ... because they've come full circle! Genius!
Near
Posted on 19-05-15, 14:53 in hiro vs libui (vs Dear ImGui?)
Burned-out Genius Developer
Post: #40 of 51
Since: 10-30-18

Last post: 1421 days
Last view: 1344 days
The biggest pro is that people know libui exists. I've actually seen it reviewed by other people online. hiro is completely unknown beyond the two of us.

hiro's basically finished, with the exception that the Mac port is always going to be quite broken, and only the GTK port (and possibly the Qt port) seems likely to ever have a TreeView control.

Really, the reason to love hiro is the automatic shared memory management. Never having to call new, never having to test for null pointers, never wondering how objects will destruct. That and never having an API call generate callbacks, which is something I've never seen another toolkit get right.

The reason to hate hiro is the multiple layers of abstraction to implement the shared memory and to avoid polluting every object file that includes the hiro headers. They really make it a nightmare from hell to debug in gdb/lldb.
Pages: 1 2 3
    Main » Near » List of posts
    Powered by AcmlmBoard XD, version 2.2.2-Lambda
    By Kawa, Arisotura, Nadia, et al
    AcmlmBoard © Jean-François Lapointe
    Page rendered in 0.138 seconds with 73 MySQL queries.
    Yes, it's an ad.