b2 - new emulator

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

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: 1090
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

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: 80
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

sbadger
Posts: 203
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey

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 | BBC B x2 | Electrn | Master | RPi x3
A600 | C64 "breadbox"| C64 C | XB360 | GB | GBC | GBA | GBASP | DS | 3DS XL & new | MD | MS
Atari 7600 | PS1-2-3-4 | PSP | Vita | SNES | GC | N64 | Wii & U | Switch | Jamma Cab | Sony PVMx2

tom_seddon
Posts: 80
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: 401
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.

sbadger
Posts: 203
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey

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 | BBC B x2 | Electrn | Master | RPi x3
A600 | C64 "breadbox"| C64 C | XB360 | GB | GBC | GBA | GBASP | DS | 3DS XL & new | MD | MS
Atari 7600 | PS1-2-3-4 | PSP | Vita | SNES | GC | N64 | Wii & U | Switch | Jamma Cab | Sony PVMx2


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 3 guests