Backdrops in mame2003-plus

[Riverstorm]

@UDb23 - Thanks for all the work on this overlay. I will be testing this tonight. I saw in the overlay thread someone posted a Battletoads overlay so I created the files and have been playing that a bit. It runs smooth with a shader and is a nice overlay but the quality is not quite as good as yours.

Are you stretching the BD to get the overlay HD? Would it have worked to make the overlay full HD and make the "dark" sides black or transparent so it's 1920x1080?

I thought of making the corners a single pixel if transparency doesn't hold coords. I'm not sure how to say that part. Basically can you have a column that's transparent and then the left side bar, game, right side bar and finally transparent column again. Does that make sense?

@Clyde - I'm a bit jealous you're able to setup 3 OS's over a lunch break. I mainly keep Windows almost exclusively for legacy gaming. I still have some old DOS games. I do remember the "birth" of DOS and well over 20 years ago I remember working at UPS using OS/2 Warp and an IBM System/36.

[UDb23]

@Riverstorm said in Backdrops in mame2003-plus:

Are you stretching the BD to get the overlay HD? Would it have worked to make the overlay full HD and make the "dark" sides black or transparent so it's 1920x1080?

Basically I created a BD with full black left side image and a right side image with just the rank boxes background (ON and OFF versions with their corresponding rank masks that are activated by the rom driver).
Coordinates same as previous to stretch the sidebars to correct ratio for 1080p.
The BD still is rendered low res but as it is just the rank background it is not noticeable.

Then a dedicated RA 1080p overlay with transparent ranking boxes is placed on top.

I thought of making the corners a single pixel if transparency doesn't hold coords. I'm not sure how to say that part. Basically can you have a column that's transparent and then the left side bar, game, right side bar and finally transparent column again. Does that make sense?

Full transparent only images for BD do hold the place but have bigger size in terms of KB vs full black; that's why I opted for the latter.
During tests I also found out that if you only apply a right side image as BD, the whole rendered area (game area+right side ) will be centered on screen: this means game area no longer centered. Therefore I still needed to add a full black left side.
It could be done with just one image with transparent game area but then you need to create masks of the same size to get the lamps light on. That would require more memory and more processing I believe.

[Riverstorm]

@UDb23 - Triumph! Simply triumph! :) Great job getting around the low res limitations. I look forward to see if that programmer is able to implement HD artwork that works on lower power systems.

Here's some old text davej (The programmer behind the crt-pi shader) on memory access when using overlays and shaders. He said the relative access figures were just away of indicating how much extra work the Pi needs to do when using shaders and/or overlays. If a read or a write of a pixel is one memory access, reading or writing the whole of a large image will take more of them than for a small image.

Some notes on memory usage.

The examples shown are for a 4:3 game displayed on a 1920x1080 screen. The game screen is upscaled to 1440x1080 to keep the aspect ratio the same. Game screens vary in resolution so I've used a rough average.

a) GPU upscales image: GPU reads game image, upscales it and sends it to the display. It can upscale (with linear or nearest filtering) to any supported resolution without extra memory accesses. Relative memory accesses = 1.

b) With overlay: GPU reads game image, combines it with overlay (which it also has to read) and sends it to the display. Needs memory from a) plus size of overlay (overlay is 30 times as big as image from game). Relative memory accesses = 31.

c) Using shader: GPU upscales game image using shader and writes it out to memory. GPU reads upscaled image and sends it to display. Needs memory from a) plus 2 * upscaled image size (upscaled image is 23 times as big as image from game). Relative memory accesses = 47.

d) Shader with overlay: As c) but also has to read the overlay whilst sending image to display. Relative memory accesses = 78.

For a 720 screen, the overlay and shader upscaled images are about half the size.

All Pis have relatively slow memory and the CPU and GPU can end up fighting over access to it. My recommendation is to overclock your memory as fast as it will go whilst still remaining stable.

If you're using shaders overclocking the GPU can help relieve pressure on memory - it doesn't use less but the access pattern changes a bit making it conflict less with the CPU. Note: crt-pi in it's default configuration was designed to work on Pi1+2s with the default GPU clock of 250MHz, by overclocking I mean reative to that. By default Pi Zeros are clocked at 300MHz and Pi3s at 400MHz. If you get overheating problems with Pi3s running shaders you could try underclocking the GPU down from 400MHz - but it might cause problems for shaders other than crt-pi.

[UDb23]

@Riverstorm far too kind! :-)

btw probably not noticeable but lit up rank is made with a circular color gradient
to simulate real light effect.

Very interesting info about memory usage; thanks!!

[UDb23]

Think I'm going to apply same method to get high res art also in Skydiver.

[Riverstorm]

@UDb23 - Excellent game! :) I don't know if there's a bug in Sky Diver. When you have a moment can you test player 2 in Sky Diver? When I would press my jump button the parachute would immediately deploy for player 2. So he would jump and deploy the chute. Player 1 works ok. Also it seems the points awarded on the landing pad for player 2 aren't working quite right either.

[UDb23]

@Riverstorm didn't try player 2 yet. Will check tomorrow and let you know.

[Clyde]

@UDb23 Great work! I'll test it on my desktop PC that has 1920x1200 (16:10) resolution.

@Riverstorm

@Clyde - I'm a bit jealous you're able to setup 3 OS's over a lunch break.

Thanks, but I "only" set up one OS then, and another at home after dinner. 😌

It certainly helps that modern Linux distributions can be installed in 15-20 minutes for at least ten years now – including all updates if internet is available – depending on the machine and storage speed involved. It also helps to know what I'm doing, having installed many encrypted Linux systems manually over the years. Although most Linux installers can set up an encrypted system automatically, the ones I know can only do that for one system and wiping the whole disk in the process. Thus the manual partitioning I did before the installation, and some little adjustments afterwards. In case you're interested, this is my final partitioning scheme:

• 1st partition for /boot of the first OS (512 MB)
• 2nd partition for /boot of the second OS (512 MB)
• 3rd partition for /boot of the third OS (512 MB)
• 4th partition for /boot of a possible forth OS, because I can! (512 MB)
• 5th partition for the encrypted LVM, and in it …
• four logical volumes for / of the different OS (50 GB each)
• one logical volume for the shared data (The rest of the 960 GB, I can't remember the exact amount in the moment.)

After setting this up in advance, it's "only" selecting the right partition and volume for / and /boot in the installer, creating the /etc/crypttab manually after the installation, and running update-initramfs -uk all in a chroot shell on the installed system to write the changes into its booting processes.

I changed my prior plans to use a combined $HOME, because at least KDE Neon and Kubuntu may have colliding settings for their different KDE versions. I now have their $HOMEs on the root volumes, the rest of the data directories are mounted on the respective $HOMEs' subdirs (like ~/Documents, ~/Downloads, ~/Pictures etc.) automatically via fstab entries – the bind option of mount is your friend.

Ironically, this post took me twice as long as one of those installations. 😊

I mainly keep Windows almost exclusively for legacy gaming.

Same here (Win 7), but I barely boot it in these times of many native Linux games and Retropie. 😉 It's highly probable that it will be my last Windows and that it'll die when Win 7's support runs out.

I still have some old DOS games. I do remember the "birth" of DOS and well over 20 years ago I remember working at UPS using OS/2 Warp and an IBM System/36.

I also played around with OS/2 and BeOS many years ago, but I never used them productively.

[quicksilver]

Not sure how far you all played into "gorf" but I definitely have some performance issues running that game. Very noticeable once you get into the third stage and the ships are dive bombing. CPU usage goes up to around 90% but never goes much higher so I'm not sure whats causing the slowdown. I'll have to test with the artwork off. Could that cause a performance hit?

[Clyde]

@quicksilver I didn't got around to check it yet, but in principle everything that give the software and/or hardware more to do can have an impact on the performance.

I'm looking forward to your results with and without the artwork.

[quicksilver]

So I tested without the artwork and the game still doesn't seem to be running full speed with mame2003+. Especially by the third level it really starts to chug. This doesn't seem like it should be a particularly demanding game. I might have to open a ticket.

[Riverstorm]

@Clyde - That's honestly quite impressive. I think your kung-fu is strong! I would classify you as an advanced user for sure. If I get stuck I know who's doorstep I am going to darken. ;) Were you able to get a hotkey snapshot to work with raspi2png? I think it would be a great utility especially for capturing snaps with overlays.

@quicksilver - Just a few posts above I listed the extra resource required when using overlays, shaders and when combining them both together if that helps. Overlays definitely have the ability to make a significant impact. I see you tested it already without though and no change.

These new overlays and BD's are like a fresh coat of paint on a car. It just makes you want to take them for a spin and rediscover them all over again.

[quicksilver]

@Riverstorm said in Backdrops in mame2003-plus:

These new overlays and BD's are like a fresh coat of paint on a car. It just makes you want to take them for a spin and rediscover them all over again.

Especially with the working light effects. So cool! If only I was better at the game and could actually see the different "lamps" light up. :)

[Clyde]

@Riverstorm said in Backdrops in mame2003-plus:

@Clyde Were you able to get a hotkey snapshot to work with raspi2png? I think it would be a great utility especially for capturing snaps with overlays.

It's still on my ever too long to-do list. I hope to finally get to it this weekend. It's not only a matter of time and leisure, but also of me having to remember wanting to do it. 😇 So, thanks for the reminder.

[Riverstorm]

@quicksilver - Lol...that's me, I have to trust the lights do work beyond Space Cadet.

@Clyde - It's no hurry but if you do I would definitely add that to my utility goodies. I took raspi2png and the date parameters you shared and made them into an executable. Then made an r2p alias which has been working well for me. A keyboard shortcut would simplify and perfect the whole process by getting rid of SSH.

[UDb23]

@quicksilver said in Backdrops in mame2003-plus:

So I tested without the artwork and the game still doesn't seem to be running full speed with mame2003+

As said previously I had the same impression that the game is slow, not only comparing with arcade videos but also already playing the first level the gameplay doesn't feel smooth.
I mean without any overlay or shader. Same happens in lr-mame2003 (std).
Maybe .78 driver is not emulated well or sound samples implementation is slowing it down.

[quicksilver]

@UDb23 I opened a ticket

https://github.com/libretro/mame2003-plus-libretro/issues/675

[Riverstorm]

Some dry reading below but there's been a lot of work done to Gorf since 0.78. Does anyone have current MAME setup to test if it works correctly on more current versions? It shows as accurate emulation in all areas except imperfect sound.

@UDb23 - Interesting thing about the Gorf is the hardware is the same as Wizard of Wor which you made a great overlay for it. Love that game.

WIP:

0.205: Removed Z80, ASTROCADE, SAMPLES, SCREEN and PALETTE MCFG macros [Ryan Holtz].

0.204: Removed AY8910/AY8912 MCFG macros [Osso].

0.202: Removed Z80CTC, Z80DAISY and WATCHDOG MCFG macros [Osso]. Fixed bad format string (includes\astrocde.h) [Vas Crabb].

0.201: Removed CD4099, ADDRESS_MAP_BANK and NVRAM MCFG macros [Ryan Holtz].

0.198: Driver and device modernization. Renamed sound device, documented pinout and added input and output callbacks. Added addressable and non-addressable output latch devices. Added watchdog timers for most games. Use memory maps instead of hacking in handlers in DRIVER_INIT. Split up base class a little [AJR].

0.185: Removed anonymous timers (video\astrocde.cpp) [Osso].

0.181: Removed audio\gorf.cpp/h and audio\wow.cpp/h. Simulate Votrax SC-01 sound [O. Galibert].

0.176: Initialize interrupt line register with 0xff (prevents initial bogus interrupts) and clear active interrupts when an interrupt related register is written (tests would be good to confirm how this works on real hardware). This fixes (MESS) 280Zzzap/Dodgem cartridge resets [Dirk Best].

0.174: Added audio\gorf.h and audio\wow.h. Allow separate Astrocade driver building [Miodrag Milanovic].

0.165: Reduced tagmap lookups in Astrocade driver [Wilbert Pol]. Converted profpac & friends to bankdev [Alex Jackson].

0.152: Moved gorf and wow sound handlers into the driver state [Osso].

0.147u1: Added layout\spacezap.lay.

0.146: Get rid of anonymous timer (savestate problem) [hap].

0.142u1: Atari Ace converted Astrocade driver to driver_device.

0.139u1: Ranger_Lennier limited the number of timers potentially produced by astrocade_trigger_lightpen() (video\astrocde.c).

0.137u2: Bryan Ischo fixed double-free error in render.c. This fixes the shifted gfx display in some Astrocade games.

0.128u5: Aaron Giles fixed black screen in Demons & Dragons and Professor Pac-Man doesn't accept coins.

0.124u1: Astrocade update [Dirk Best]: Update src\mame\includes\astrocde.h to use an XTAL value. Clear interrupts if they are no longer valid. Added the knob inputs.

0.123u6: Added layout\gorf.lay. Fixed debug assertion in Astrocade driver.

0.116: Aaron Giles fixed screen top/left cut off.

0.115u2: Aaron Giles added border support to the Astrocade driver. Extended the starfield generation out into it. Extended the blanking region out farther to match information from the flyers and set the default scale/offset of the games to crop appropriately. Aaron Giles fixed recently introduced bug in Astrocade driver relating to collision detection.

0.115u1: Removed machine\astrocde.c. Added layout\tenpindx.lay. Rewrote Astrocade driver [Aaron Giles]: Fully implemented all function generator modes. Implemented pattern board according to schematics, including timing. Fixed interrupt handling. Rewrote Astrocade sound emulation according to patent. Sound generation now uses proper LFSR for noise effects. Added partial support for Ten Pin Deluxe, including sound board emulation and internal layout.

0.104u5: Adam Bousley added save state support to the Astrocade driver.

0.98u2: Aaron Giles replaced direct access to Machine->scrbitmap in Astrocade driver with the use of force_partial_update().

0.88u3: Nathan Woods moved some variable declarations in sound\astrocde.c to the tops of their respective groups.

0.88u2: Changed sndhrdw\astrocde.c to sndhrdw\wow.c. Added includes\astrocde.h. Removed sndhrdw\astrocde.c. Improvements to Astrocade driver [Frank Palazzolo]. Fixed collision detection in all games. Added NVRAM handling to Robby Roto and Professor PacMan, still not working always but self-tests pass. Fixed bugs in Astrocade sound code (noise generator bug, out of bounds memory access bug and changed to stream system). Switched Astrocade sound to stream system. Support stereo in wow, robby, gorf and profpac (Sounds great now!!). Added LEDs and coin counters. All activecpu_get_reg() calls from Astrocde games have been replaced with proper 16-bit Z80 port support through memory system.

[UDb23]

@Riverstorm Also found this:

• 0.115u1: Changed Z80 CPU and 2x Astrocade clock speeds to 1789772 Hz, palettesize to 512 colors and VSync to 60.054442 Hz. Added 'Speech' dipswitch.

Posted also in @quicksilver bug report.

Usually versions near .78 can be backported while more recent seem impossible to implement in mame2003 according to previous developers' feedback.

[UDb23]

GORF
Interesting & fun stuff
On the Astro Battles screen, the last two invaders can be slowed down to a crawl if you fire like crazy.

On the Laser Attack screen, if you shoot all the enemy ships except for the laser shooters, you can sit forever on the far left hand side of the screen. There were two ROM versions, and this trick only works on the first version.

GORF is actually an acronym for Galactic Orbiting Robot Force according to an early flyer.
"Gorf was in fact named for "frog" backwards, but why? "Frog" was Jay Fenton's nickname (developer).

Gorf was originally intended to be a tie-in with Star Trek: The Motion Picture, but when the game designers read the film's script, they realized that the concept would not work as a video game. The player's ship resembles the Starship Enterprise.