@mrnoholster I don't think that they'll be implemented in lr-mame2016 any time soon.

As I said, you can install the mame emulator and try running the game with it - it's the same emulator you've seen running on PCs with the effects you mention.

@zerojay said in Vectrex emulator with GPU rendering:

It looks like the pull request for this was accepted 3 days ago.

Exactly! It's a bummer, as my plan was to use a Raspberry PI to emulate in an original Asteroids cocktail cab. The other games I put in there work well (Space Invaders, Galaga, etc.), but the Asteroids and Asteroids Deluxe just aren't up to par. Sounds like my only real option is to use a PC/MAME that can handle more advanced effects. I recognize that vector games relied on specific monitor hardware to get the desired effects, but as a novice, it just seems crazy that there isn't a good way to emulate 50-year-old visuals on a modern (albeit low-powered) PC and monitor. I'd be happy to forego the glow if I should just SEE the bullets. Maybe someone smarter than me will eventually work out a way to size them up! :)

sorry.I wasn't asking for the game roms,just the already to go set up really,I can add the roms myself

thankyou

@neurocrash Just in case anyone else gets the same idea, I was able to run Dos Vectrex Emulator in Retropie Dosbox, and while it looks great, it is far too slow on my Raspberry Pi 3. I think it runs at about 50% of the original speed.

Cheers

@herb_fargus Perfect; thanks a lot !

@grant2258 Thanks Grant. I can't understand what's in that link, I'm afraid....beyond my pay-grade. But I'm OK with using the USB keypad to make it work.

@BuZz said in MAME 2003 "vector" games only displaying 1/4 of screen after updating - what needs to be edited?:

BTW the vector games did work on the last binary so it may have been a core option affecting this. there has been some fixes since then though including some relating to the new vector code and the settings, but the last binary is not "old" (It's from the 11th October). I will update the binary though.

Thank you @BuZz if there are still problems with vectors in mame2003 after this binary update I will work to resolve them.

thanks for your reply mate , i will check it out

@caver01 provides all details in this great post.

@SpudsMcToole I just edited that post that @UDb23 is linking to above with a note that setting the display resolution is no longer necessary with AdvanceMAME 3.x because it now has improved Pi support for video settings.

As for the fancier filters like bloom and trail effects, I would love to see this, but these options are not available on the older versions of MAME that are otherwise working nicely on the Pi. However, it would be interesting to explore newer versions of MAME that are experimentally available to see if it is possible to get an advanced shader like this working. Effects like those that were running on the old AAE emulator in Windows were amazing, but if I recall, even back then it required a decent GPU to pull them off. Can the Pi handle such a challenge, even if it was being done almost a decade past? I have doubts. I have settled for high-res vectors, some transparency and flicker, and maybe some shadow masks on color.

MAME shaders aside, I am curious about what could be done with a retroarch shader in this regard. I don't really know much about them, but someone like @davej might be able to pull a rabbit out of hat, even if it meant making a few compromises. To make it worthwhile, we would first want vector games to render in full-res on lr-mame2003, not to mention, someone like davej would need to have more than a passing interest in old vector games to generously contribute his time to the effort.

@quicksilver thanks, really appreciate that you found it useful.

@UDb23 You are referring to the concept of overscan. I think old CRTs often had slightly different borders where the image could be drawn. As a game builder, you maybe had exact specs on the monitor that would be used in the arcade cabinet, but best practice included placement of important items (like cockpit readouts, score text, etc.) within the "safe" area so that the image could be adjusted to fill the screen. Actually, the image may have been adjusted to go beyond the screen, ensuring all areas are covered. It's a bit like printing ink on paper using a full-bleed, knowing that the final piece will be cut such that your image goes edge-to-edge.

Anyway, I am glad you got it figured out.

@caver01 Modified rc file as suggested.
Thank you so much, now it works correctly :-)