b2 - new emulator

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
Kecske Bak
Posts: 676
Joined: Wed Jul 13, 2005 7:03 am
Location: Treddle's Wharf, Chigley
Contact:

Re: b2 - new emulator

Postby Kecske Bak » Tue May 16, 2017 11:15 am

Working beautifully on Linux (Manjaro KDE x64) - I look forward with playing with this tomorrow!

Screenshot_20170516_131357.png

Coeus
Posts: 464
Joined: Mon Jul 25, 2016 11:05 am

Re: b2 - new emulator

Postby Coeus » Tue May 16, 2017 11:31 am

ctr wrote:I built it on Windows with cmake 3.8.1.

gen_6502.py failed because I've got python3. I replaced all the .iteritems() with .items() and that fixed it.


That's interesting. I am building on Arch Linux and that also has python3 as the default, i.e. what you get when yoy just run 'python'. I just created a symlink to force it to use the right version but it may be worth explicity invoking python2 if that's what's needed.

I like the ability to clone a running machine into a new window. I am not sure if it is a bug or not, but when doing so the clones machine starts with the default keymap, not the one from the cloned machine.

User avatar
lurkio
Posts: 1284
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: b2 - new emulator

Postby lurkio » Tue May 16, 2017 11:32 am

I can't seem to get the latest release (0.0.2) to run on macOS 10.10.5.

If I double-click the .app icon, I'm told the application "requires OS X 10.11 or later".

If I do Show Package Contents and navigate to the b2 executable in the MacOS directory, I get a Terminal window and a b2 window that both pop up, but the b2 window is just blank (black). The title of the b2 window is "b2 [0.000x]".

:?:

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 1:05 pm

It looks like I only managed to set the OS X version options for compiling, not for linking, so the binary still advertises itself as 10.11+ only, and is quite possibly won't then only 10.11-compatible anyway. I'll fix this later, and that should hopefully let it run on 10.7-10.10...

The OS X 10.12.5 launching problem is a complete mystery to me... I wonder where the -p comes from, and what it's for? Initially I'll probably just add some extra logging in, which won't help (sorry...) but might help track it down.

--Tom

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 1:08 pm

Rich Talbot-Watkins wrote:Possibly everything is too wide, because Thomas Harte concluded that Beeb pixels are not exactly square, but actually slightly taller than they are wide. That MODE 7 basically looks OK to me though.


Unfortunately everything *is* slightly wrong, but it's at least consistent ;) - on a real BBC all the modes are the same width, and the aspect ratio for the bitmap modes is 1.2:1 rather than the 1.25:1 implied by the pixel counts. I decided to leave things like that, because the scaling looks a bit ugly with point sampling, but now that the BBC display is filtered by default I should probably just make it the correct aspect ratio.

Rich Talbot-Watkins wrote:I noticed there's no anti-aliasing - does that mean you're actually building a very big bitmap which you can divide by 3, 6 or 12 (for regular modes' pixels) or by 4 (for MODE 7 subpixels)? There seems to be less than a pixel's gap between MODE 7 glyphs so maybe there's something else going on there.


Nothing so clever, I'm afraid: the Mode 7 glyphs are simply scaled up to 16 x pixels wide before being antialiased. Then 1µsec = 1 Mode 7 glyph, and the effective pixel clock is then always 1µsec = 16 Mode 0 pixels (or 8 Mode 1/4 pixels, 4 Mode 2/5 pixels, 2 Mode 8 pixels...) in both bitmap modes and Mode 7.

The glyph scaling does mean that not all columns are the same width, and the gap (which is in the left column) is currently one of the narrow ones. I think I will tweak this for the next version (see attached).

--Tom
Attachments
mode7_323332.png
likely "new" font
mode7_233233.png
current font (as of v0.0.2)

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 1:22 pm

Rich Talbot-Watkins wrote:More feedback: it looks as if you're not displaying screen data during the vertical total adjust section if the vertical displayed total hasn't yet been reached (see attached disc image; new rows should be scrolling on pixel-by-pixel, not waiting until the entire row is visible).


Thanks... the adjustment period is currently always blank, so I'll sort that out...

Coeus wrote:I like the ability to clone a running machine into a new window. I am not sure if it is a bug or not, but when doing so the clones machine starts with the default keymap, not the one from the cloned machine.


The code does work that way, so it's not a bug in that sense, but you're right that it's not very useful (and it's certainly not much of a clone). The way the emulator options are handled needs a bit of prodding anyway so I'll revisit this when I do that.

--Tom

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

Re: b2 - new emulator

Postby Rich Talbot-Watkins » Tue May 16, 2017 1:44 pm

tom_seddon wrote:Nothing so clever, I'm afraid: the Mode 7 glyphs are simply scaled up to 16 x pixels wide before being antialiased. Then 1µsec = 1 Mode 7 glyph, and the effective pixel clock is then always 1µsec = 16 Mode 0 pixels (or 8 Mode 1/4 pixels, 4 Mode 2/5 pixels, 2 Mode 8 pixels...) in both bitmap modes and Mode 7.

Are you plotting the screen scanline-by-scanline (each as its own primitive) or building up the entire screen as a texture and blatting that as a single quad? It sounds as if it's having to treat Mode 7 as a special case currently. Does it handle mixed modes, in particular the strange case of mixed Mode 7 / Mode 4 (which I think was demonstrated to work on real hardware recently)?

ThomasHarte
Posts: 363
Joined: Sat Dec 23, 2000 5:56 pm

Re: b2 - new emulator

Postby ThomasHarte » Tue May 16, 2017 2:00 pm

If it helps any as to the mystery: attempting to launch b2.app 0.0.2 on macOS 10.12.4 from anywhere other than /Applications tells me that "Initialisation failed" due to "unknown short option: -p". Launching from /Applications works without issue.

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: b2 - new emulator

Postby ctr » Tue May 16, 2017 3:14 pm

I tried commit 1f8c690 which sets a text rendering offset. The text looks great! It is much better than the linear filter.
Attachments
b2d.png

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: b2 - new emulator

Postby Elminster » Tue May 16, 2017 3:57 pm

ThomasHarte wrote:If it helps any as to the mystery: attempting to launch b2.app 0.0.2 on macOS 10.12.4 from anywhere other than /Applications tells me that "Initialisation failed" due to "unknown short option: -p". Launching from /Applications works without issue.


Oddly it didnt work launching from /Applications using the main icon the first time I put it there. But subsequent times attempts it did. I wonder if it is because I had closed/unmounted the dmg.

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 4:47 pm

Thanks for the additional info - I'm still none the wiser though. (In case you can't tell, this is my first time trying to distribute an OS X app.) The stupid thing is supposed to run from anywhere :(

I'll add some kind of command line logging functionality to the next build, and maybe that will help narrow things down...

--Tom

Coeus
Posts: 464
Joined: Mon Jul 25, 2016 11:05 am

Re: b2 - new emulator

Postby Coeus » Tue May 16, 2017 4:50 pm

Tom, I don't lnow how different it is running on OS/X vs. Linux but on Linux it seems it works out which directory its executable is in and then expects an assets subdirectory under that which is not how Linux application are usually installed, though I think it is how Windows applications are installed.

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 5:28 pm

Rich Talbot-Watkins wrote:
tom_seddon wrote:Nothing so clever, I'm afraid: the Mode 7 glyphs are simply scaled up to 16 x pixels wide before being antialiased. Then 1µsec = 1 Mode 7 glyph, and the effective pixel clock is then always 1µsec = 16 Mode 0 pixels (or 8 Mode 1/4 pixels, 4 Mode 2/5 pixels, 2 Mode 8 pixels...) in both bitmap modes and Mode 7.

Are you plotting the screen scanline-by-scanline (each as its own primitive) or building up the entire screen as a texture and blatting that as a single quad? It sounds as if it's having to treat Mode 7 as a special case currently. Does it handle mixed modes, in particular the strange case of mixed Mode 7 / Mode 4 (which I think was demonstrated to work on real hardware recently)?


Yes, it should handle everything correctly, though not all the corners have been especially thoroughly tested just yet ;)

The screen is plotted microsecond by microsecond; the emulator produces a continuous stream of VideoDataUnit structs (video.h), representing various types of pixel data or TV signals. Then there's a bit of code (TVOutput.cpp) that consumes these and transforms them into output data. (The TVOutput stuff has a super-basic CRT-like state machine, which is mainly there so that the screen is positioned naturally, based on the timings, without having to do any calculations based on CRT register values or whatever. It also runs asynchronously, in response to the PC vblank - there's a lockless circular queue type of thing so the BBC emulator just produces data on one thread and the TV emulator consumes it on another).

Having each Mode 7 glyph be 16 pixels wide then actually removes any special cases - you can think of it as performing ahead of time the stretch that you get naturally from the continuous scanout with the 12MHz (???) SAA5050 pixel clock compared to the 16MHz mode 0 pixel clock. (A Mode 7 glyph is 12 pixels wide, but it's basically the same width as 16 Mode 0 pixels.) Then 1µsec of video output is always 16 PC pixels wide: it's 16 x Mode 0/3 pixels, 8 x Mode 1/4/6 pixels, 4 x Mode 2/5 pixels, 2 x Mode 8 pixels, or 1 x the width of a Mode 7 glyph.

The extra vertical resolution isn't a special case either - 1 µsec of BBC display data always corresponds to a 16x2 area of the display texture, but in bitmap modes the same data is copied to both lines. So the encoding for 1 µsec of Mode 7 display output (16x2 1bpp + 3-bit foreground colour + 3-bit background colour) is different from the encoding for 1 µsec of bitmap display output (16x1 4bpp), but they can be distinguished by the consumer so they'll get decoded properly .

--Tom
Last edited by tom_seddon on Tue May 16, 2017 8:37 pm, edited 1 time in total.

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 5:59 pm

Coeus wrote:Tom, I don't lnow how different it is running on OS/X vs. Linux but on Linux it seems it works out which directory its executable is in and then expects an assets subdirectory under that which is not how Linux application are usually installed, though I think it is how Windows applications are installed.


Yes, that's a good point. The OS X and Windows builds are doing the right thing, and the Linux version just kind of inherited that. I've only ever run it straight from the build folder myself, I must admit...

I suppose the assets folder should go somewhere in /usr/local/share or something. How do programs typically find their stuff? My immediate instinct would be to have a sort of search path style of affair for the assets, so it looks for them in <exe folder>/assets/, $(XDG_DATA_HOME)/b2/, <exe folder>/../share/b2/, something like that... does that sound reasonable?

--Tom

Coeus
Posts: 464
Joined: Mon Jul 25, 2016 11:05 am

Re: b2 - new emulator

Postby Coeus » Tue May 16, 2017 6:59 pm

tom_seddon wrote:Yes, that's a good point. The OS X and Windows builds are doing the right thing, and the Linux version just kind of inherited that. I've only ever run it straight from the build folder myself, I must admit...


I raise it in case it was relevant to the OS/X versions not running, not knowing how this normally works on OS/X, but it would be good to make this an installable package. So far, though, I have indeed run it from the build directory too.

tom_seddon wrote:I suppose the assets folder should go somewhere in /usr/local/share or something. How do programs typically find their stuff? My immediate instinct would be to have a sort of search path style of affair for the assets, so it looks for them in <exe folder>/assets/, $(XDG_DATA_HOME)/b2/, <exe folder>/../share/b2/, something like that... does that sound reasonable?


The 'bin' directories generally don't have sub-directories with assets in, just the main executable. This has the advantage that searching the executable PATH (the PATH environment variable) is fast because it tends to have few entries in it but has the disadvantage of putting bits of the application in different places.

For files the user will probably not want to replace with their own versions you could probably stick to /usr/local/share/b2 and /usr/local/lib/b2. The distinction is that /usr/local/share is for data that does not depend on the architecture of the executing machine so, for example, a WAV audio file is a standard format that is the same on different architectures so the disk noise samples would be a definite candidate for somewhere under /usr/local/share/b2. The same would be true of BBC ROM images etc. /usr/local/lib would be a better choice for a file that has to be built to match the platform, i.e. if it is different on 32/64 bit CPUs or big/little-endian byte order etc.

There's another complication in that /usr/local tends to be used for things built by the admin/user of a particular Linux box and then installed whereas /usr tends to be used by things built into a distribution package so it is normal to have the notion of a 'prefix' which would then be either /usr or /usr/local. That can then be included in the build process.

I think the XDG_DATA_DIR etc. would be more relevant for things the user might want to replace of for saving configurations etc.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: b2 - new emulator

Postby Elminster » Tue May 16, 2017 7:26 pm

All the different Linux distros tend to do it slightly different anyway

I think I would follow the standardish way of putting things in the right place for the main distros, but I wouldnt bother until everythign was stanble enough to create a proper packages .rpm, or .deb etc that can eaily be installed, uninstalled etc. i..e make sure you have a good uninstall script before installing it all over the place.

I aways put my own stuff in one directory under /opt because I am too lazy to muck aroun with creating packages and nobody much out side of propriety Unix use /opt much.

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: b2 - new emulator

Postby ctr » Tue May 16, 2017 10:31 pm

I realised that it wasn't just the text but everything in the GUI that had the offset problem. I turned off the filtering and the text offset and hacked SDL's world transformation to move everything by half a pixel:

Code: Select all

diff --git a/src/render/direct3d/SDL_render_d3d.c b/src/render/direct3d/SDL_render_d3d.c
index 68d8a95..c3adb17 100644
--- a/src/render/direct3d/SDL_render_d3d.c
+++ b/src/render/direct3d/SDL_render_d3d.c
@@ -1277,8 +1277,10 @@ D3D_UpdateViewport(SDL_Renderer * renderer)
         matrix.m[2][1] = 0.0f;
         matrix.m[2][2] = 1.0f;
         matrix.m[2][3] = 0.0f;
-        matrix.m[3][0] = -1.0f;
-        matrix.m[3][1] = 1.0f;
+        //matrix.m[3][0] = -1.0f;
+        //matrix.m[3][1] = 1.0f;
+        matrix.m[3][0] = -1 - 1.0f / renderer->viewport.w;
+        matrix.m[3][1] = 1 + 1.0f / renderer->viewport.h;
         matrix.m[3][2] = 0.0f;
         matrix.m[3][3] = 1.0f;
         IDirect3DDevice9_SetTransform(data->device, D3DTS_PROJECTION, &matrix);


All of the UI looks much crisper, especially the menu borders which are exactly one pixel wide. The beeb output is unaffected. (When the beeb output is scaled up it is slightly affected, but it is just differently blobby rather than better or worse.)

Is this what everyone else sees with the original code?
Attachments
b2e.png

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

Re: b2 - new emulator

Postby tom_seddon » Tue May 16, 2017 11:12 pm

The top image is what it's supposed to look like; that's what it looks like for me on OS X, Linux, and Windows using the defaults (so no UI filtering and no half-pixel text offset).

One thing you could try, which literally only occurred to me just now, is run the emulator using D3D11 or opengl. Run it from the command prompt with `b2 --help' and check out the -r option. You might have more luck with opengl or direct3d11. (My PC also has opengles2, for some reason... I imagine that'll look the same as OpenGL?) I'd be interested to hear what options your PC has (the --help display will list the drivers available) and how you get on with each.

Anyway, I've put the code for the half pixel text offset in, and there'll be a build with that option in shortly, so you can try that too. But if the problem affects the entire UI, obviously the half pixel text offset isn't going to solve it; and if direct3d11/opengl work for you, then what I'd much rather do is just take these extra options out and just suggest using the direct3d11 or opengl driver instead :)

I don't think this problem is affecting anybody else (is that the case?).

Once those two options are gone, maybe I can think about taking the BBC display filtering option out too, so it's always filtered... I don't like the way the change can't take effect immediately (an SDL limitation).

--Tom

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: b2 - new emulator

Postby ctr » Wed May 17, 2017 1:30 am

I tried d3d11. The good news is that I get the same results with and without the half pixel offset. The bad news is that it's comically broken on this ancient GPU.

I tried the half-pixel text offset in a previous post. It has clear text but fuzzy menus as you'd expect.

I'm really puzzled by this offset thing. The dx9 half pixel offset is a known thing. The SDL code for rendering the textures already accounts for it. The additional offset I added should cancel this out. If my PC's graphics driver had no half pixel offset that would seem to explain it, but a simple dx9 application that I wrote works with exactly one half-pixel offset. Which seems to be SDL's default.

Anyway, it's possible to work around this without hacking SDL. You can put the offset in the call to SDL_RenderGeometry:

Code: Select all

diff --git a/src/b2/dear_imgui.cpp b/src/b2/dear_imgui.cpp
index 784e149..1bf5a5c 100644
--- a/src/b2/dear_imgui.cpp
+++ b/src/b2/dear_imgui.cpp
@@ -321,7 +331,10 @@ void ImGuiStuff::Render() {
                 int *indices=(int *)&draw_list->IdxBuffer[idx_buffer_pos];
                 ASSERT(idx_buffer_pos+(int)cmd.ElemCount<=draw_list->IdxBuffer.size());
 
-                rc=SDL_RenderGeometry(m_renderer,texture,vertices,num_vertices,indices,(int)cmd.ElemCount,NULL);
+            SDL_Vector2f translation;
+            translation.x = -0.5f;
+            translation.y = -0.5f;
+                rc=SDL_RenderGeometry(m_renderer,texture,vertices,num_vertices,indices,(int)cmd.ElemCount,&translation);
                 ASSERT(rc==0);
 
                 ASSERT(cmd.ElemCount<=INT_MAX);


Although I'm still not convinced the problem doesn't lie somewhere else. I might have time for another look tomorrow.

Rendering with d3d11:
Attachments
b2f.png

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

Re: b2 - new emulator

Postby Rich Talbot-Watkins » Wed May 17, 2017 6:13 am

Yes, d3d11 has half pixel offsets by default, while d3d9 doesn't. Could explain the differences in various machines. On mine it looks great until you turn on UI filtering.

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

Re: b2 - new emulator

Postby Rich Talbot-Watkins » Wed May 17, 2017 8:35 am

tom_seddon wrote:Having each Mode 7 glyph be 16 pixels wide then actually removes any special cases - you can think of it as performing ahead of time the stretch that you get naturally from the continuous scanout with the 12MHz (???) SAA5050 pixel clock compared to the 16MHz mode 0 pixel clock. (A Mode 7 glyph is 12 pixels wide, but it's basically the same width as 16 Mode 0 pixels.) Then 1µsec of video output is always 16 PC pixels wide: it's 16 x Mode 0/3 pixels, 8 x Mode 1/4/6 pixels, 4 x Mode 2/5 pixels, 2 x Mode 8 pixels, or 1 x the width of a Mode 7 glyph.

I just found the code that returns 1us strips of Mode 7 (Get16WideRow()). I think the problem there is that you're forcing 6 pixels into a 16 pixel wide strip by unevenly distributing the widths (so some pixels take 2 texels and others take 3). In jsbeeb I built an antialiased bitmap using 4 different levels, so each teletext pixel appears to be the same width. But this is only any good if the image is plotted at a fixed 1:1 scale, otherwise the "prefiltered" glyphs will then be filtered again by the GPU when scaling.

Image

That's why the ideal thing is to either treat MODE 7 scanlines as a special case and have the GPU stretch them to the correct width (as they only have 480 pixels across), or - better - actually treat a 1us strip of scanline as having 48 pixels across (divisible by both a 16MHz and 12MHz pixel clock) and let the GPU filter it down to size however it wants. However some older GPUs won't allow textures greater than 2048 across, so that limit becomes an issue then too.

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: b2 - new emulator

Postby ctr » Wed May 17, 2017 2:43 pm

Rich Talbot-Watkins wrote:Yes, d3d11 has half pixel offsets by default, while d3d9 doesn't. Could explain the differences in various machines.


Ah! The obvious explanation didn't occur to me. Maybe I'm the only person using the d3d9 rendering and it's just broken.

If this is the case then a fix would be to add the offset in the call to SDL_RenderGeometry (as above) only when using d3d9.

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

Re: b2 - new emulator

Postby tom_seddon » Wed May 17, 2017 11:44 pm

Excellent, thanks for that. I'd managed to convince myself earlier today while in the car that the half-pixel offset was indeed always necessary, but being away from the PC I didn't get any further than just thinking about it :)

What I've done is add the half pixel offset to the SDL_RenderGeometry call as you suggest, so when you're using D3D9, everything is always offset, filtering or no. (This is now on the git master branch.) And so it looks like the menu borders were actually always wrong on my laptop (I'd never realised), and when I tried the old build on my desktop in Windows (had only tried it in Linux before) a number of the font glyphs were very obviously rendering wrongly without the offset. So this is looking like a good change...

(As for whether there are further problems, I don't think so, but there's no shortage of evidence that I could be mistaken ;) The other SDL functions look to add the -0.5 offset in for you, so they should be fine as they are. But SDL_RenderGeometry just passes your vertex data straight through.)

EDIT: I've pushed a fix for D3D11 too, which was broken on my PC in exactly the same way. (I'm *sure* I'd tried this! - but clearly not, and my best guess is that I entered the command line options for the wrong config in Visual Studio (which I do all the time) and didn't notice. Either that or I'm going insane.) The fix was in the SDL code, so after doing a git pull, you'll need to do a git submodule update to get it.

--Tom

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: b2 - new emulator

Postby ctr » Thu May 18, 2017 1:02 am

tom_seddon wrote:(As for whether there are further problems, I don't think so, but there's no shortage of evidence that I could be mistaken ;) The other SDL functions look to add the -0.5 offset in for you, so they should be fine as they are. But SDL_RenderGeometry just passes your vertex data straight through.)

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.

tom_seddon wrote:EDIT: I've pushed a fix for D3D11 too, which was broken on my PC in exactly the same way. (I'm *sure* I'd tried this! - but clearly not, and my best guess is that I entered the command line options for the wrong config in Visual Studio (which I do all the time) and didn't notice. Either that or I'm going insane.) The fix was in the SDL code, so after doing a git pull, you'll need to do a git submodule update to get it.

I gave it a go. It looks great with both d3d9 and d3d11 now!

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

Re: b2 - new emulator

Postby tom_seddon » Thu May 18, 2017 1:18 am

\:D/
ctr wrote:I gave it a go. It looks great with both d3d9 and d3d11 now!

Does it look the same with UI filtering on and with it off? (It's supposed to, and it does on my laptop at least.) If the UI filtering option is now redundant, I'll get rid of it...

--Tom

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: b2 - new emulator

Postby Elminster » Thu May 18, 2017 8:50 am

Not sure if you still need this info but the messages logged to the console on Mac (10.12.5) when you try to start from the icon in the Application folder and it fails with the '-p' messages is:

Code: Select all

May 18 09:43:12 imac27 b2[8161]: b2: 2 command line arguments:
May 18 09:43:12 imac27 b2[8161]: argv[0]: /Applications/b2.app/Contents/MacOS/b2
May 18 09:43:12 imac27 b2[8161]: argv[1]: -psn_0_1130772
May 18 09:43:14 imac27 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.oneshot.0x10000025.b2[8161]): Service exited with abnormal code: 1
May 18 09:43:14 imac27 Kite[3503]: at didTerminateApp


Still able to open with the show package drill down work around of course.

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

Re: b2 - new emulator

Postby tom_seddon » Thu May 18, 2017 12:26 pm

Thanks, most helpful - eventually I found some info on Stack Overflow and managed to reproduce it on my Mac. I've fixed the code on github and will upload some binaries later today probably.

--Tom

User avatar
ctr
Posts: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: b2 - new emulator

Postby ctr » Thu May 18, 2017 3:30 pm

tom_seddon wrote:Does it look the same with UI filtering on and with it off? (It's supposed to, and it does on my laptop at least.) If the UI filtering option is now redundant, I'll get rid of it...

Four snapshots of the basic prompt with the filter dialog and messages window visible. I restarted the emulator before each snapshot to ensure the filter settings were in effect. They all look the same.

EDIT: Of course, the Filter BBC setting does have an effect if you resize the beeb output.
Attachments
b2all.png

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

Re: b2 - new emulator

Postby tom_seddon » Fri May 19, 2017 12:16 am

I uploaded binaries for version 0.0.4: various fixes, plus some Mode 7 improvements.
Rich Talbot-Watkins wrote:That's why the ideal thing is to either treat MODE 7 scanlines as a special case and have the GPU stretch them to the correct width (as they only have 480 pixels across), or - better - actually treat a 1us strip of scanline as having 48 pixels across (divisible by both a 16MHz and 12MHz pixel clock) and let the GPU filter it down to size however it wants.

It now does this, effectively, though by stretching - stretching 12 pixels into 16 isn't too much of a bother, and the results are (or so I managed to convince myself!) the same as shrinking 48 pixels into 16. And comparing it side by side to my Master, it certainly does look more authentic.

There's still room for some improvement, though, as the difference between the blurred edges and the sharp edges can sometimes be noticeable, even when you've got the GPU filtering on top. One advantage of starting with the higher-res version might be that some smoothing could be included in the high-res copy, and then that would come through to an extent in the shrunk-down one... need to try that at some point...

--Tom

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: b2 - new emulator

Postby Elminster » Fri May 19, 2017 9:41 am

tom_seddon wrote:Thanks, most helpful - eventually I found some info on Stack Overflow and managed to reproduce it on my Mac. I've fixed the code on github and will upload some binaries later today probably.


=D> Now opens direct from main package icon in Applications.

Selfishly my wish list of feture I use a lot in Beebem (PC and Mac where implemented) are:

Paste from Host O/S; and
import/export to/from disc (to host O/S).

i.e. I develop on a Mac and use Emulator to test and convert to a real bbc basic file.

Getting those feature on and I can use B2 in more real world usage (for me)


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 3 guests