xxOToTOxx

Wow, word travels fast, you beat me to it.

For anyone waiting: https://github.com/DirtBagXon/hypseus-singe/releases/tag/v2.10.2

@lezzi87 - Those files are in this thread. Or use the first post and the Base64 decoder to get the links.

Yep, some gun game improvements coming. Including wide borders for Sinden users.

Bezels After the hiatus we have some more features coming in hypseus. Integrated bezel support: Coming soon in a release near you.

Get your soldering irons at the ready: https://github.com/DirtBagXon/hypseus_scoreboard

Thanks, Another coming addition will be the ability to add a hardware annunciator to Space Ace. It will be fully customizable, so you can go all authentic or create some funky new peripheral addon....

Dragon's Lair USB Hardware Scoreboard Game testing:

For the Arduino hackers and hardware geeks out there. A work-in-progress: Dragon's Lair USB Hardware Scoreboard

Of course - If you are using RetroPie just pull the update via RetroPie-Setup from source. Other distros will be catching up on their next release. Or compile from source easily yourself following repo instructions. The Pi will not support the full resolution overlays due to it being under powered, but 32bit overlays and gamepad support are all tested and working

Hypseus Singe v2.10.1 Couple of major additions in the new Hypseus Singe release. 1. SDL_GameController support, so the option to use a simplified constant MACRO driven config rather the traditional Joystick API that Daphne used (hot plugging and gamecontrollerdb.txt supported): [KEYBOARD] KEY_UP = SDLK_UP 0 0 AXIS_LEFT_UP KEY_DOWN = SDLK_DOWN 0 0 AXIS_LEFT_DOWN KEY_LEFT = SDLK_LEFT 0 0 AXIS_LEFT_LEFT KEY_RIGHT = SDLK_RIGHT 0 0 AXIS_LEFT_RIGHT KEY_COIN1 = SDLK_5 0 BUTTON_BACK KEY_COIN2 = SDLK_6 0 0 KEY_START1 = SDLK_1 0 BUTTON_START KEY_START2 = SDLK_2 0 0 KEY_BUTTON1 = SDLK_LCTRL 0 BUTTON_A KEY_BUTTON2 = SDLK_LALT 0 BUTTON_B KEY_BUTTON3 = SDLK_SPACE 0 AXIS_TRIGGER_RIGHT KEY_SKILL1 = SDLK_LSHIFT 0 0 KEY_SKILL2 = SDLK_z 0 0 KEY_SKILL3 = SDLK_x 0 0 KEY_SERVICE = SDLK_9 0 0 KEY_TEST = SDLK_F2 0 0 KEY_RESET = SDLK_0 0 0 KEY_SCREENSHOT = SDLK_F12 0 0 KEY_QUIT = SDLK_ESCAPE 0 0 KEY_PAUSE = SDLK_p 0 0 KEY_CONSOLE = SDLK_BACKSLASH 0 0 KEY_TILT = SDLK_t 0 0 END 2. 32bit full size overlays in Singe games. Scanlines enabled: 32bit overlays will be default now in all Singe games, existing and in the new full overlay versions that will follow. You can run 8bit sprites on a full overlay if you really want some nostalgic fun Use: -8bit_overlay To update your existing Hypseus install, just overwrite the hypseus.exe file with the new version from the zip. https://github.com/DirtBagXon/hypseus-singe/releases/latest

This is really good stuff. I have two things that spring to mind about doing this, I suspect more will arise as games are created. 1. The hitboxes should, as you have stated, be aggregated the largest box areas to minimise the checks in the code, we don't want to create large lists of if/else statements in LUA. Not only for the inefficiency but also due to the resource consumption it will cause, particularly on smaller CPU devices like the RPi. Which leads me to the next point. 2. The overlay size these hitboxes are created within. All the original gun games were created by RDG on a 360x240 overlay (if I recall correctly). i.e. half the 720x480 original video resolution. All the existing gun games are created with this overlay scale, including the HD versions thanks to Karis's magic in the LUA. This again has the advantage of keeping resource consumption low and making game decision execution faster. The overlay size in Hypseus is based on original Singe 1 codebase, this is the reason is works so well on the Pi currently due to the 8bit nature and restrictions on the overlay size. If overlay sizes are increased then more resources are required, I know this has even affected some PC CPU setups on large resolution games. So, and I admit there is a vested interest in keeping new gun games playable on the Pi, I think using the current overlay size would be a benefit if you want these games available to a wider audience (The Sinden Pi guys will go crazy for a new Singe Gun Game). This would probably also aide your calculations in the algorithm as it would have less pixel area to concern itself with, maybe at the loss of some finer control, but hey these are lightguns, accuracy is only so "accurate" Throwing open to discussion here.....

I probably should have posted a .bat file example - sorry. Most generic games use the traditional /singe/ subfolder. You can of course change the MYDIR variable at the top of any of the main .singe files to change the path as desired, but by default this one will be: hypseus.exe singe vldp -framefile singe\arcadex1\arcadex1.txt -script singe\arcadex1\arcadex1.singe -sound_buffer 2048 -fullscreen

The frontend is nothing to do with me, it is also in really early development, I have no idea if the author will include Singe/ActionMax games. At this point it appears to be just Daphne games (the most complex config). An update was pushed a little while ago stating: "WARNING This program is a state of flux right now and for the forseeable future." If you are not familiar with development code, probably better to stick with the provided example batch files from the main repo: windows-batch-files-v2.8.3.zip from here: https://github.com/DirtBagXon/hypseus-singe/releases/latest You will likely have to customize them. Even without a config file hypseus will use the default keys. These are all described in the only config file: hypinput.ini See the defaults here: https://github.com/DirtBagXon/hypseus-singe/blob/master/doc/hypinput.ini There is no config.bat Does the game start and you can't input keys? If so try '5' and then '1'. If the games doesn't start at all using the frontend. Then use the bat files. If there are issues then you can provide log files.

Arcade Xperience Vol.1 - (mazinger4life) @mazinger4life Arcade Xperience Vol.1. Here is the hypseus port. https://dl.orangedox.com/x7ZhXnMWIzX0ELBTEj

Follow the other thread from around here:

Be aware that as you still have the black bars in the video, you can shunt the top overlay down a little. "-vertical_stretch 18" to "-vertical_stretch 20" - maybe - personal preference of course.

Fantastic to see these options being produced, and the use of FFMpeg. It's such a powerful tool, just needs a little practice. Looking at the FrameCount and Duration in mediainfo, looks spot on - really nice 👍 What Daphne/Hypseus arguments are you using to get the overlay framing correct with this video ?

Looks very promising

That would involve adding +100 to the last column, NOT to the second column. But use hypjsch. That is exactly what this tool will help you calculate. SDL sometimes doesn't automatically make it controller "2", hypjsch will tell you what SDL is detecting it as and give you the correct config to add to the third column.

It's in the pre-releases: https://github.com/cdurbin1970/HypseusFE/releases HypseusFE_1_8_22_22_x64.zip

You could also try playing with: https://github.com/cdurbin1970/HypseusFE Although it's very early in development.

This thread is primarily about Hypseus (Daphne fork). See: https://github.com/DirtBagXon/hypseus-singe There is lots of info on the first post in this thread. Look for Windows Templates in this thread, and Windows .bat files from the repo. Hypseus uses the same ROMS, framefiles and video/audio sources as Daphne. The HD video sources to replace the original SD M2V are linked in the first post of this thread (and throughout). Did you use https://github.com/DirtBagXon/hypjsch (this is also in the Windows release zip) to help determine the button SDL values ?

I think we have the original aspect source. See below.... I think I can say with some certainty that the "4:3" we are seeing in the two YouTube videos is a result of CRT overscan (hardware adjusted), resulting in a loss of video material across the horizontal axis: Squeezing a "fixed view" image to 4:3 to show the full current image here: Now looking at the Stern promotional video, we see a loss of width and lost content on each side: Note: Cropping on left and right of palm trees. So we are not stretching or compressing the video aspect. Also the same in the other YouTube video (on arcade CRT), also note this is positioned slightly differently: If we then look at the Stern video and take the video taken from direct feed (not CRT screen shot). We see a full width in this scene: But in-game, on the CRT, we see it as: Again missing detail on both far horizontal edges. So hardware overscan. However, the current video source and aspect ratio is correct by my reckoning....

Here's an interesting promotional video from Stern: The opening scenes do look to be in 4:3, but then subsequent scenes show the letterbox. I would think it may have been "stretching" involved here. Using -x 1440 -y 1080 on the WS video here to acheive the stretching.... I dunno some playing maybe can be done. The '-nolinear_scale` version.