Atari800 port with native GLES2 rendering.

[Andrey]

Hello!)

I hacked some Unreal Speccy Portable GLES2 rendering C++ code to work with this great emu.
And now... it works at full speed in full screen with custom zooming option. Also there is a filtering option.

Prebuilt version for raspbian:
http://sourceforge.net/projects/atari80 ... p/download

Source code is integrated into main Atari800 project code repository.
http://atari800.cvs.sourceforge.net/vie ... /atari800/

Note: you need to setup correct video mode for PAL/NTSC machines (proper video/audio sync and vsync).
edit /boot/config.txt

720p mode:

Code: Select all

hdmi_group=1
hdmi_mode=19

1080p mode:

Code: Select all

hdmi_group=1
hdmi_mode=31

for NTSC version (60 Hz):
720p mode:

Code: Select all

hdmi_group=1
hdmi_mode=4

1080p mode:

Code: Select all

hdmi_group=1
hdmi_mode=16

(see http://elinux.org/RPiconfig for more info)

By default emulator used PAL version because it more compatible with software (default refresh rate in raspbian is 60 Hz, so you really need to configure your video mode).

[Vanfanel]

Awesome work, Andrey!

This, precisely THIS is the kind of work we need to improve gaming on the Pi!!
I will test as soon as I can! (I just hope "Alternate Reality : The City" doesn't suck me in like last time and I end losing months of real life thanks to that game!)

Any chance of seeing the GLES backend of Scummvm fixed for the Pi? (it has one but it doesn't work on the Pi). MAME on GLES2? Now things are really taking off!!

[welshy]

Good Job! I have an alternative to Atari800, Atari++. It runs in GTK (Under “X”) but is FULLSCREEN in Console with no need for Config changes. Features and Performance wise there is little to distinguish them, however, Atari++ has a better GUI and MUCH greater compatibility with ROMS/Disc Images than Atari800. I WOULD have preferred using ALTIRRA (In my opinion THE BEST Atari 8Bit Emulator!), but there ISN’T a Linux version (That I have yet discovered).
Here is the Link to my “Guide” - http://www.raspberrypi.org/phpBB3/viewt ... 78&t=24729

It gives instructions on how to compile/use the Program as well as some detail of the Best games available for the System/Trivia

Nice to see another Atari 8 Bit fan! It’s the Machine I learnt 6502 Assembler on (Atari 400)! These computers arguably had no peer as a gaming machine until the release of the Famicom (NES) in Japan in 1983. Renowned Dropzone programmer Archer MacLean stated “The Atari, being the Porsche of home computers, is capable of running Dropzone 2.5 times faster than the 64 and can handle any amount of blobs on screen, even when you release a Strata Bomb. It is visually, sonically etc., identical and about 12K shorter. However, the 64 is still a respectable BMW316”. When you consider the C64 was released 3 YEARS later (1982) it’s an ever greater accomplishment! Atari’s custom chipset was designed by the legendary Jay Miner (Atari VCS-TIA, Amiga Chipset etc), a “True” Genius!

[Andrey]

Atari++. It runs in GTK (Under “X”) but is FULLSCREEN in Console with no need for Config changes

Hello! And what about performance in FullHD resolutions? It can render 60 fps without frames skipping? Stretching in software? I dont believe in this. But i'll try it to compare, thanks!
And what about vsync? Is scrolling in "Boulder Dash" smooth?

Any chance of seeing the GLES backend of Scummvm fixed for the Pi? (it has one but it doesn't work on the Pi). MAME on GLES2? Now things are really taking off!!

I'm not familiar with code of this emulators, but i can consult someone who can build this emus about how to use GLES2 code.

[Andrey]

wow, fast approval on Pi Store:

http://store.raspberrypi.com/projects/atari800

[welshy]

Andrey
Constant 60 FPS, YES. FULLSCREEN at high Resolution, depends on your definition I suppose! My RPi is set to the HIGHEST POSSIBLE RESOULUTION (Its running on a PC Monitor) though the Pixel count is as the native hardware (320X240) (Only Polygon based Console Emulators can actually increase the output resolution rendered). It runs Dropzone (Probably the most intensive game graphics wise pixels rendered/scrolling) EXACTLY as native hardware (I checked!)

[Vanfanel]

@whelsy, I appreciate your work but this Atari800 port is vastly superior to your Atari++ port.
Rpi hardware can, via dispmanx or GLES, upscale any resolution to fullscreen 1920x1080 (for example). Any raster graphics-based game/emulator can be upscaled this way: the final image is hardware-scaled to full native resolution. No need to have vector graphics (like those 3D-consoles you mention), it's a different issue you're talking about. This emulator (as any amulator or game on the Pi SHOULD DO) upscales the final output using the GPU to fullscreen thus freeing up this task from the CPU.
As for propper double-buffered and vsync-ed display, your port totally obviates these, resulting on tearing all the way. No smooth scroll is possible without those.
In the other hand, Atari800 by Andrey (the best game/emu ported I've seen on the Pi, who has understood what good emulation implies at last) shows smooth scroll in games, as it's intended in the original system.
Anyway, it's not your fault: default SDL 1.2.x is really broken on the Rpi. Double buffer is broken, vsync is impossible, sclaing has to be done in software and blitting is done in the slowest, worst way (just measure how much time is spent in the damn blitting functions, compared to emulation itself).
I corrected the first three issues by implementing a dispmanx backend to SDL itself, look here:
https://github.com/vanfanel/SDL12-kms-dispmanx
I have double buffer and vsync working, and also full native resolution scaling using a hardware overlay via dispmanx interface.

...but blitting on ARM is still SLOW AS A DOG and is killing performance in every emulator and game I've tried. On X86, it uses waaaaaaay faster MMX implementation. With an OpenGL or GLES implementation, it can be simulated by using blending, I believe. (Have you gone that far, Andrey?)

But I disgress. This is how an emulator should be ported and released, period. I'm fed up with jerky and tearing graphics trying to pretend they look like the original machines, because they don't.

[welshy]

Vanfanel
Agreed! I accept and am aware of all your points! (I was just trying to avoid getting technical with my reply!). I think my atrocious “cut + paste” job (I cribbed it from a previous discussion regarding the virtues of Atari800 vs. Atari++ in their ORIGINAL form!) led you to miss interpret my intention in the post (Reading it myself again I can see how). I didn’t mean to imply Atari++ SDL was BETTER than Andrey’s GLES hack (How COULD it be?), just Atari++ is superior to Atari800 as an emulator! (And an alternative emulator for GLES implementation). From what I have experienced, for sure, smooth scrolling IS NOT SDL’s forte (On the RPi)!

On a technical note (I can see I’m talking to a guy with excellent knowledge/skills) I have posted on occasion regarding “Drivers” on the RPi, it has always seemed odd to me that the compliant drivers (GLES etc) are the ones NOBODY seems to use for a supposed “Open Source” machine? (From what I have gleaned Open GL and SDL are the standard graphics drivers in Linux). To me the analogy would be releasing a Windows based machine that didn’t use Direct X But some “other” proprietary Driver (That Nobody used)! I previously had a discussion with another user about this issue but got my head BITTEN OFF by a Moderator (Without, what I would consider an acceptable answer). Personally I consider a definite “FLAW” of the RPi. Any thoughts on the issue?

One Last Thing, I have seen your work in regards to Driver improvement, GOOD JOB!

[ghans]

It's a ARM "Problem". I mean ARM consumer desktops are
nowhere near predomiance on the market. Desktops use
Open GL. ARM CPUs are used in mobile and embedded devices.
Those devices use OpenGL ES. The Pis SoC is not meant for a
desktop by design.

ghans

[Andrey]

Constant 60 FPS, YES. FULLSCREEN at high Resolution, depends on your definition I suppose!

I compiled and tried this emu (sdl frontend in terminal without X).
Menus and settings is very complex.
Mouse is required (i need to control from keyboard).
Screen size is small and not stretched to all TV area.
No vsync (as i thought).

Try to play scrolling games (Boulder Dash, River Raid, ...) on my port of Atari800 compare it with SDL Atari++ and feel the difference

[Vanfanel]

I was playing Boulder Dash yesterday with Atari800.
Indeed, this is what I call perfection:

-The Menu is keyboard-driven, integrated in the emulator and accessed via F1, it has every option at hand! Remember how important it is on the Rpi. X on the Pi is irritatingly slow, so no emulator should be using that crap (yes, I said it, X in 2013 is crap).

-Smooooooooth as a real Atari 800XL! I can't insist enough on how important it is: the Atari 800 (like most computers and consoles of that time) was designed with smooth scroll in mind. It was the idea of a natural 2D movement back then. Ignore this, and you're totally screwing the experience.

In sum, I feel like an Atari 800 XL machine is now living inside my Rpi
(Sadly It can't say the same about other machines because it's the only emulator this well integrated I've seen on the Rpi).

[welshy]

Andrey
As I posted before, please DONT take it that I was being disparaging about your work (I did say “Good Job”). I think my atrocious “cut + paste” job (I cribbed it from a previous discussion regarding the virtues of Atari800 vs. Atari++ in their ORIGINAL form!) led you to miss interpret my intention in the post (Reading it myself again I can see how). I didn’t mean to imply Atari++ SDL was BETTER than your GLES hack (How COULD it be?), just Atari++ is superior to Atari800 as an emulator! (And an alternative emulator for GLES implementation). From what I have experienced, for sure, smooth scrolling IS NOT SDL’s forte on the RPi!

But Atari++ being superior is my personal opinion I suppose (But it definitely had better Disc Image/Rom compatibility than Atari800 from the testing I did). Regarding your point of “Screen size is small and not stretched to all TV area” again is down to preference in Emulation. Most of the early computers DIDN'T fill the screen (Apple II, Atari 8 bit Line, C64, ZX Spectrum etc) they were an embedded square (It just happens to be auspicious that the resolutions of these “embedded” squares are proportionate to 16:9). The problem comes with computers like the Amiga, some software cleverly circumvented this (Speedball comes to mind), so if the embedded square is expanded to fill the screen in its entirety none of this additional area will be visible! (Which is why I plumped to use uae-0.8.29 for Amiga emulation instead of UAE4ALL). Of course even if some systems did fill the vertical area the original aspect ratio was 4:3 so black bars should be visible when running on 16:9 as to prevent distortion of the image. But again, this is a personal opinion with regards to "Perfect" emulation of these Systems!

[realbrucest]

Great, thanks Andrey!!

Now... is it possible for you (one of these days) to give us a little and general guideline about rendering the video output onto a GLES surface

Agree with Vanfanel, this opens the can of worms

Thanks again for your work on this mate!

[Vanfanel]

Now... is it possible for you (one of these days) to give us a little and general guideline about rendering the video output onto a GLES surface

Agree with Vanfanel, this opens the can of worms

I totally agree with my compañero sevillano here, the real porting revolution starts the moment you share your knowledge on rendering video to GLES2 surfaces, when you get time to do so

[Andrey]

(Sadly It can't say the same about other machines because it's the only emulator this well integrated I've seen on the Rpi).

Try Unreal Speccy Portable . It's smooth too.
But smoothness works only in PAL (50Hz) modes.
Watch many demos with smooth effects:
SHOCK MEGADEMO EXTASY MEGADEMO BRAIN SURGERY INSULT MEGADEMO

[Andrey]

Now... is it possible for you (one of these days) to give us a little and general guideline about rendering the video output onto a GLES surface

Rendering in GLES2 surface is simple - you just need to render into memory byte array with emulator native screen WIDTH x HEIGHT dimensions.
Many emulators have this buffer built in and update it each frame.

Then you need to transfer this buffer to GLES2 texture each frame. And draw quad (2 triangles) with this texture zoomed on whole screen.

Transferring from byte buffer to GPU memory is simple with calling glTexSubImage2D (look at gles2.cpp, line 330).
In this example memory buffer returned with Handler()->VideoData() function and has 320x240 indexed colors (color palette used).
Then this indexed colors translated in real colors in fragment (pixel) shader by reading palette texture (uploaded in GPU).

Also you can look at atari800 sources in folder src/sdl/video*.cpp. The difference of Atari/ZX Spectrum is in screen dimension and palette size.

[ghans]

Is this of any interest to the guys of

http://atari800.sourceforge.net/ ?

I think they would welcome a OpeGL ES backend , or do i have
misunderstood something ?

ghans

[realbrucest]

Is this of any interest to the guys of

http://atari800.sourceforge.net/ ?

I think it is. GLES 2.0 support surely is a very nice add for them. I'll give them a shout myself in a sec. No prob.

And also Andrey, very kind of you

[Andrey]

I think they would welcome a OpeGL ES backend , or do i have
misunderstood something ?

Maybe... I fill support request form.
http://sourceforge.net/p/atari800/support-requests/6/

[Vanfanel]

Thanks A LOT for the explanations, Andrey! And for the source to experiment and learn from!
I'm sure I will come back to ask some questions...

[Andrey]

Vanfanel

You're welcome

[ksangeelee]

I've noticed that, when using a joystick (PS3 controller, USB HID mode), the keyboard response becomes very slow (a lag of 2 to 3 seconds between pressing a key and the resulting action).

This applies both to 'in emulation' key handling, including 'Select', 'Option', etc. and to the user-interface menu's key handling.

Interestingly, there doesn't seem to be any lag in processing the keys assigned to the keyboard-joystick, so I guess it's not caused by the underlying SDL library being slow to generate events.

In all other respects, the emulator is running perfectly, and the keyboard lag doesn't have any effect on the emulation speed.

Has anyone else experienced this? Note, I haven't tried the non GLES2 version - I suspect it will behave similarly.

[Pate]

Hello Andrey!

Thanks for sharing the source code for this! I am trying to use it as an example when improving the graphics blitting code in my WIP rpix86 emulator, but have not yet managed to get anything besides a white screen.

I pretty much took your video_rpi.cpp, video_gles2.cpp and video_gles2_shader.cpp codes, combined them into a single source file gles_video.c (I converted the C++ things to plain C), trying not to break anything. It compiles OK and I have checked that none of the gl functions return an error, but as I am not at all familiar with OpenGL ES, I am having a hard time figuring out what am I doing wrong.

Do you happen to have any ideas what might be the most probable reason for plain white screen? I have tried forcing the palette to have all black etc, but nothing seems to have any effect, including commenting out the whole gles2->Draw(screen_width, screen_height); line.

Thanks!

Pate

[Pate]

Ah, okay, I solved the white screen problem: I hadn't realized I need to initialize the OpenGL ES in the same thread as where I do the drawing! I use a separate rendering thread in rpix86, and that caused the white screen problem.

Okay, now I can continue with actually getting something useful on the screen.

Pate

[Andrey]

I pretty much took your video_rpi.cpp, video_gles2.cpp and video_gles2_shader.cpp codes, combined them into a single source file gles_video.c (I converted the C++ things to plain C), trying not to break anything.

Wow, you need to host this C sources anywhere because of GPL license
I'll send them to Atari800 devs (they coded only in plain C, and i'm very lazy to rewrite C++ to C %).