b2 - new emulator

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Coeus
Posts: 706
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: b2 - new emulator

Postby Coeus » Fri May 19, 2017 10:02 am

ctr wrote:I think you're right. I was confused because SDL renders bitmaps correctly (e.g. the beeb output), and the font is just a bitmap, but the font was coming out wrong. But, as you say, bitmaps rendered through SDL_RenderGeometry aren't using the same code. So it makes sense.


So is this a deliberate feature of SDL? Is there a rationale to why SDL_RenderGeometry is different? or might this be a bug in SDL? If the latter would it make more sense to temporarily work around it in the embedded version of SDL and submit upstream?

User avatar
Rich Talbot-Watkins
Posts: 1198
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: b2 - new emulator

Postby Rich Talbot-Watkins » Fri May 19, 2017 10:05 am

Looks much better =D>

It looks as if you're doing the same as jsbeeb now: rendering a "pre-filtered" glyph, stretched from 12 to 16 pixels with 4 colour levels from background to foreground. Like I think we both said, that could look weird when the GPU is then filtering a stretched version of that.

Shrinking on the GPU could give better results, but if it's shrunk to less than 50% (as is likely) you'd need to create mipmaps as well or it might not look right.

tom_seddon
Posts: 110
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: b2 - new emulator

Postby tom_seddon » Fri May 19, 2017 1:24 pm

Coeus wrote:
ctr wrote:I think you're right. I was confused because SDL renders bitmaps correctly (e.g. the beeb output), and the font is just a bitmap, but the font was coming out wrong. But, as you say, bitmaps rendered through SDL_RenderGeometry aren't using the same code. So it makes sense.


So is this a deliberate feature of SDL? Is there a rationale to why SDL_RenderGeometry is different? or might this be a bug in SDL? If the latter would it make more sense to temporarily work around it in the embedded version of SDL and submit upstream?

My repo is the upstream :-| - the RenderGeometry stuff was originally an OS X-and-Linux-only patch attached to a bug report, to which I added Windows D3D9/D3D11 support. Then I uploaded it to a github... I get the impression that official SDL isn't interested until it has a software renderer, so that is probably its home for now.

But you're quite right about RenderGeometry, of course. The rationale for having it pass the data straight through, unprocessed, was that this was sort of its spec (insofar as it has one) - but really it might as well just add the offset when appropriate, since it's probably the right thing to do for virtually all (or more) probable uses.

I can add a toggle to switch it off.

--Tom

User avatar
sbadger
Posts: 268
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: b2 - new emulator

Postby sbadger » Thu Oct 12, 2017 1:35 pm

Hi Tom.

Is there any chance of ever being able to use shaders?
There is a shader called crt-royale that can simulate a crt, and it does it very well, the best there is at the moment. On displays over 1080p its remarkable!

here is a wiki on it with example screen from a SNES game
https://emulation.miraheze.org/wiki/CRT_Shaders#CRT-Royale

stew
A3020| A3000x3| BBCBx5 | Electrn | Masterx4 |RiscPC| RPix3
A600 | C64 bbin x2|C64C | Toastrackx2 |QL | XB360&1X |GB |GBC |GBA |GBASP | DS | 3DS XL x2| MD | MS
Atari 7600 | PS1-2-3-4| PSP |Vita |SNES|GC|N64|Wii & U |Switch|ArcadeCab |Sony PVMx2

tom_seddon
Posts: 110
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: b2 - new emulator

Postby tom_seddon » Sat Oct 14, 2017 10:02 pm

Maybe at some point, but there's a bunch of internal stuff I need to fix first, and there's some stuff actively on the roadmap that I'll be doing before it: joysticks, UI revamp, debugger, 6502 second processor, save state.

It won't be on all platforms, at least not initially. SDL doesn't support shaders or render targets natively, and I'm using SDL to do pretty much everything. Anything rendering stuff it doesn't support has to be written once for each combination of platform and graphics API. So I'll probably do this for one of the D3Ds first, probably D3D9 if the shaders will work (since SDL picks D3D9 by preference if it's available, and I expect support is a bit wider-spread, assuming anybody's still even using a non-D3D11 GPU...), or D3D11 if not. Then see how I feel about doing OpenGL after that :)

--Tom

User avatar
Lion
Posts: 410
Joined: Sat Mar 14, 2009 6:56 pm
Location: Woodside, California
Contact:

Re: b2 - new emulator

Postby Lion » Sat Oct 14, 2017 10:33 pm

Those kinds of shaders usually emulate NTSC televisions/monitors, don't they? PAL screens look a little different.

User avatar
sbadger
Posts: 268
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey
Contact:

Re: b2 - new emulator

Postby sbadger » Sun Oct 15, 2017 9:05 am

Lion wrote:Those kinds of shaders usually emulate NTSC televisions/monitors, don't they? PAL screens look a little different.


Some yes, but the more advanced shaders simulate most aspects of crts. Crtroyale specifially is so configurable people have come up with different configs to match specific makes and models of unit. Sony PVM etc.

http://i.picpar.com/rjV.png - eg this isn't actually a Sony PVM screen shot, but shader settings.
A3020| A3000x3| BBCBx5 | Electrn | Masterx4 |RiscPC| RPix3
A600 | C64 bbin x2|C64C | Toastrackx2 |QL | XB360&1X |GB |GBC |GBA |GBASP | DS | 3DS XL x2| MD | MS
Atari 7600 | PS1-2-3-4| PSP |Vita |SNES|GC|N64|Wii & U |Switch|ArcadeCab |Sony PVMx2

tom_seddon
Posts: 110
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: b2 - new emulator

Postby tom_seddon » Wed Apr 18, 2018 2:09 am

I've set up a continuous integration/rolling builds type of affair for b2. This just gets the latest code whenever there's a change, and tries to build it and make a release out of it.

Windows is up and running, so you can now always get a version with the latest code. Details here: https://github.com/tom-seddon/b2#rolling-windows-builds

There's also an OS X build, which appears to work, but the output file is (so far) just discarded: https://travis-ci.org/tom-seddon/b2

Linux users don't seem to really be into binary builds, so they'll continue to have to build it themselves...

Originally I'd planned for this to be just be a way of producing a random zip that you could download at your own risk, but getting it part-working has got me thinking, and I'm now probably going to abandon manual releases. (They're a bit of a pain to do.) Instead, I'll set the CI servers up to just publish every successful build to the GitHub releases page - which appears to be a thing you can do - and then anybody that wants a binary build can grab the latest one. There won't be version numbers, and instead each build will be named by its git commit hash. Might add a build date in there or something, so you can tell whether one build is older or newer than another. And I'll change my workflow a bit, to reduce the likelihood of the releases page getting swamped by piles of crappy broken versions that don't run...

--Tom

User avatar
tricky
Posts: 2293
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: b2 - new emulator

Postby tricky » Wed Apr 18, 2018 5:52 am

Thanks Tom, I'm happy to build from vs on windows, but from a trusted source (like you), assuming others can't inject their stuff, this produces a much lower barrier to entry without removing any options.