C64emu new release
- Bezel reflection not blurred on some hardware (some GPUs do not support the reuse of render targets or array fetching within a for loop - fixed)
- When saving BMP image files, the red and blue color components were swapped (fixed)
- Reset disables multi-SID (fixed)
- Gameplay replaying does not handle multi-SID settings correctly (fixed)
- SID read-only registers (POTX/POTY/OSC3/ENV3) were not saved in the state files nor in the gameplay recording files (fixed)
.: Improvements :.
- Emulation and rendering are now running in separate threads, which should help eliminate lag on slower PCs
- Rewritten sound synchronization to eliminate pops and clicks, audio latency has also been reduced (can be fine-tuned in the config file)
- More stable scope and spectrum analyzer
.: New features :.
- 64-bit compile in separate executable, which may or may not be faster on your computer
- Experimental NTSC VIC-II model (unfortunately I don't have any NTSC C64, so I could only rely on the VICE test programs, so not everything works properly yet, but in general it's somewhat functional)
- In SID player mode, NTSC tunes will automatically switch to NTSC VIC-II model
- Gameplay recordings can be rendered as image sequences with audio in a separate WAV file, for creating video files with external programs (sound output is muted during rendering)
- SID video rendering function in SID player mode even with visualizers as image sequence + WAV (automatically records the music from the beginning and stops at the end if the HVSC songlength database is available)
- New visualizer mode that shows only the oscillators, without the mixed output.
- Game controller support (beta with very primitive functionality and not yet mappable, I will improve it soon)
- 1351 mouse emulation with mouse, touchpad or analog game controller (mouse grab is only activated in fullscreen mode)
.: Minor changes :.
- If there is no config file, the default SID model for the newly created one will be 8580R5, with surround effect disabled
- The system menu structure has slightly changed due to the new features
Feel free to leave a comment.
Cheers,
DaemonPig
Excellent! No more audio glitches :)
ReplyDeleteThanks, I'm glad to hear it :)
DeleteNew version! (Just when I have to sleep.) 😋
ReplyDeleteI straight away noticed the difference in the glow in the bezel.
Will try the controller and mouse support tomorrow!
(And the saving of frames to images .. will see what cool gif's I can build with that.) 😎
Thanks!
You're welcome! FYI, the joystick handling is still rudimentary, because after I started implementing it, I noticed several bugs in the emulator that took a long time to fix, and I didn't want to delay the next release any longer, so currently only analog rudders are considered directions and all buttons are fire buttons, so e.g. digital direction buttons are fire buttons at the moment, which is not a good thing. I also wondered how nice it would be to be able to export either GIF or MP4 directly from the emulator, but reading through different licenses and unfortunately both GIF and H264 encoding are subject to licensing fees. It would even be possible to export H264 video with FFmpeg, but then I would have to open the source, which I don't want to do. In any case, if someone has the desire, a lot of storage space and even more time, he/she can even generate MP4 with 3rd party software from the frame files and the WAV file.
DeleteIf you manage to make a GIF and feel like sharing it here, I'd love to see it :)
Another solution might be Cisco's OpenH264, but I'd have to implement at least an AVI container format to which I could put the audio in the same WAVE RIFF format I'm currently using, because it's definitely free and doesn't take up most space anyway (and significantly easier and faster to transcode with 3rd party software). If I don't link the codec, just use the runtime library that can be installed separately, Cisco will pay the license fee for the H264 encoding.
DeleteBut it's certainly no more important than the 1541 emulation, so it's such a long time before I'll implement it, or not at all, I don't know yet :)
I actually much prefer my programs to have no 3rd party dependencies, so chances are there will be no native video export.
OBS capture is a good choice anyway, but it doesn't guarantee frame skip, since the emulator itself can lag if the host OS decides it has better things to do.
The current joystick support is really good. All the sticks and pads I've got do the analogue x and y for the directions. The two I have that do the hat for directions can also be switched to be analogue x-y. 👍
DeleteI tried out the png+wav export. Works beautifully. 😊 It took me a couple of tries to realise it wasn't saving immediately, and I had to render out the frames after I finished recording, but that worked well. From there creating a GIF is easy: drag all the PNG's into Screen2GIF by Nicke Manarin (free!), "Reduce Frame Count" (1 for 1) to drop every second frame (GIF supports 50 frames a second, but most players can't cope with more than 25FPS), select all frames and "Override" to set them all to 40ms (25FPS), "Remove Duplicates" at "100% Similarity" to combine identical frames, "Resize" 200% (nearest neighbour) if you want it a bit bigger, and then delete/edit things in the time-line and Override the time of some frames to cut it down to what you want.
..and then "Save As", GIF format, using the KGySoft encoder, Wu Quantizer, Palette Size 16, Ditherer "none", Endless Loop, Allow Delta, Allow Clip, and give it a file-name. 😊 ..Just a few pointers there for anyone who's never used it before, as GIF's are a little different to video.
IMHO no urgency doing a GIF exporter when Screen2GIF can import a PNG sequence by drag+drop, and has such incredibly polished editing and optimising options.
A short version of the Bruce Lee GIF I recorded here:
https://drive.google.com/file/d/1hZk2S_s70cOHq36lvpFteEUHSdWbC4X6/view?usp=sharing
The full 12.5 minute version is here, if anyone wants to download it.
(It'll play a little slow in some viewers coz the frame rate is quite high compared to many GIFs.. But Firefox/Chrome/Edge will play it well.)
https://drive.google.com/file/d/1hTYeSiKCQ2Tjm68a__ub4BsTpYWO9Fsf/view?usp=sharing
Or I put a two minute, and then a twelve minute version of the GIF up on Mastodon, if you want to see how social-media handles/converts the file:
https://oldbytes.space/@level106/115301945128185208
I did also build the mp4 video with sound using ffmpeg, but that's an even longer talk, so I'll make that another post. 😄
Okay, so making a video from the png's and wav isn't tricky. You can drop a folder of .png files in Davinci Resolve and it will be interpreted as a video, you just need to tell it the frame-rate (50FPS). You might need to stretch the audio a little to match, but also, not tricky.
DeleteBut because I'm so used to extracting frames from MAME's funky MNG saving format and rebuilding a video with FFMPeg, I used that, FFProbe, SoX, and Audacity. All free tools that will run on any PC/Mac. A few complex commands, but I've kept them as separate steps and heavily commented them:
ffmpeg -framerate 50 -i frame\brucelee-%08d.png -vf "scale=iw*4:ih*4" -sws_flags neighbor -sws_dither none -vcodec libx264 -preset slow -crf 10 brucelee_c-4xvid-50fps-mute.mp4
# Use FFMpeg (free!) to take the 44,998 .png's exported from the C64emu emulator and create a video at 50 frames per second, scaling 4x with no smoothing (nearest neighbour), compress as h264, quality 10 (gives a quite high quality, big file.) In this example I renamed the PNG's to brucelee-00000001.png through to brucelee-00044998.png, eight digit numbers, hence the %08d argument. If I'd left them as the original ten digit 0000000001.png to 0000044998.png, in a "frame" folder, it would be frame\%10d.png ..If I recall, don't try deleting the first "x" images to change the start point. I think ffmpeg really wants the first image to be number "1", and just won't find the PNG's if it doesn't start with some zero's and a one dot png
ffmpeg -i brucelee_c-4xvid-50fps-mute.mp4 -vf "scale=1440:1080,setsar=1" -sws_flags lanczos -sws_dither none -c:v libx264 -preset slow -crf 10 -r 50 brucelee_d-1080vid-50fps-mute.mp4
# Rescale the 4x video to exactly 1440x1080 (giving a 1080p video in traditional PAL 4:3 aspect ratio), using "setsar" to reset the pixel aspect ratio, with smooth scaling and no dithering.
# I dropped the .WAV file from C64emu into Audacity (free!) to remove the DC offset and made it stereo. I didn't need to do that. :) Nothing wrong with using the mono .WAV file C64emu exported. But I called my resulting stereo file brucelee-audio-02-norm-stereo.wav
# Using FFProbe (in the ffmpeg package), I determined that the 50-frames-per-second video I built is 14 min 59.96 sec
ffprobe brucelee_d-1080vid-50fps-mute.mp4
# That's a bit longer than the .wav file, which is 14 min 57.72 sec.
ffprobe brucelee-audio-02-norm-stereo.wav
# Maybe I shouldn't be using exactly 50FPS? Mr DaemonPig? VICE had a similar problem with audio-drift in its exported AVI video files, which was only recently fixed, and that caused me all manner of issues to sync, until I worked out that I should just scale the WAV file to match the duration of the MP4.
# FFMPeg has ways to stretch audio, but it seems to try to pitch-correct things in ways I never worked out how to fix, so I found a free audio tool called SoX.
sox.exe brucelee-audio-02-norm-stereo.wav brucelee-audio-03-0997x.wav speed 0.99751100048
# I want to slow the 14:57.72 WAV to be 14:59.96, the duration of the video
A bit of maths. I use https://www.omnicalculator.com/conversion/hours-to-seconds-converter
# 14 min 57.72 sec is 897.72 sec 14 min 59.96 sec is 899.96 sec
Type "897.720000 / 899.960000 =" into Google and get 0.99751100048
This is my "speed" setting. (I can never remember which number is divided by which .. sometimes I'll just try it both ways around and see which gets the right duration. hehe.
...
(continued)
Delete# Now I do a quick bit of maths to work out where I want the video to start. Title screen and music start at PNG image 7090 (actually it's 7080, I think I mis-calculated, so missed 3/4 of the first note of music.) At 50FPS frame 7090 is at 141.8 seconds (2min 21.8 sec on the hours-to-seconds-converter website), so that's my start point.
# I choose to end on the fire-screen after the big boss. PNG image 44914, coz it's a nice yellow. :) That's 44914/50=898.28 seconds, or 14min 58.28 seconds.
# If you prefer to do this stuff visually, you can put the silent video into VLC, find your approximate point, use Playback?JumpToSpecificTime to get to the beginning of any second, and press "e" to step forward a frame at a time and count how many frames in you want to start/end. (14 frames divided by 50, say, would give your .28 seconds end.)
# I edit brucelee-audio-03-0997x.wav in Audacity ..I could cut the end at 898.28 seconds if I wanted a clean end, fade-out, etc. But FFMPeg will cut it for me, so here I can just select from 0:00.00 to 141.8000 sec and delete that to get my start point. (It's here I realise I've cut most of the first note, so I just make it silent till the second note to hide my mistake.) :-p
# I save this to be brucelee-audio-04-0997-toptail.wav
..I could probably do this in sox, but I like to do the sound visually, and see how well my calculations match up the music.
ffmpeg -ss 141.8000000 -t 898.280000 -i brucelee_d-1080vid-50fps-mute.mp4 -i brucelee-audio-04-0997-toptail.wav -c:a aac -b:a 196k -ar 48000 -shortest -c:v copy brucelee_e-1080vid-50fps-aac.mp4
# Use FFMPeg to combine the 1080p video and the stereo audio, cutting the beginning and end of the video so it starts on the title screen, and ends at the end of game flames. The cut of the beginning and end only happens to the video, so already did the same cut to the audio in Audacity so they'll match. (They should match exactly, but the -shortest argument will end the overall video when either the audio or video ends, if we choose to be lazy and not cut the end of the audio .. the video file is just copied from the previous file, not recompressed .. the audio is compressed as aac.
# The combined 1080p video with sound looks great in VLC Player! But I upload it to YouTube and it's .. weird and glitchy:
https://www.youtube.com/watch?v=1spjxQet4mE
# Perhaps copying the video while merging in the audio wasn't right. I should've maybe done "-c:v libx264 -preset slow -crf 10" to recompress the video instead of "-c:v copy". (Ah yeah! Now I remember! Always reprocess the video if cutting the beginning.. I was probably missing starting key-frames and stuff.)
ffmpeg -i brucelee_e-1080vid-50fps-aac.mp4 -c:a aac -b:a 196k -ar 48000 -c:v libx264 -preset slow -crf 10 -r 50 brucelee_f-1080vid-50fps-aac.mkv
So I just re-process the .mp4 file, recompressing the video, and recompressing the audio, and putting it in an .mkv container just for paranoia. That's now up on YouTube, and looks great: ??
https://www.youtube.com/watch?v=Ij4coYVpAp8
I was planning to answer at length later, but I'll write it down quickly to see if it helps you find the best setting:
DeleteFFmpeg accepts fractional numbers as framerate parameters, so audio resampling is not necessary. To calculate the framerate, use the following formula:
clocks_per_sec / clocks_per_frame
For PAL (6569R3, 312 raster lines, 63 clocks per line):
985248 / (312 * 63) = 50,124542124542124542124542124542
and for NTSC (6567R8, 263 raster lines, 65 clocks per line):
1022727 / (263 * 65) = 59,826089499853758408891488739397
I don't know how many decimal places FFmpeg handles, but for videos of a few minutes, I'm sure the sound won't be out of sync if you specify 3-4 decimal places.
In principle, the MP4 timebase is actually numerator and denominator based, so you could give it 985248 and 19656, but I'm not that familiar with the FFmpeg CLI how to do that, but it's perfectly fine to use a fractional number as framerate.
Your GIFs are super cool BTW!
DeleteI think maybe you've played with Bruce Lee before :D
Thanks for the detailed instructions on the creation steps!
In the next version, I'll make it optional to save only every even frame, so the 25 framerate will not only require less configuration, but will also take less space to export, not to mention much less time to render.
I'll send you a FFmpeg command line parameterization that worked for me later, I just need to remind myself exactly how it was, because I didn't write it down.
DeleteThanks for the quick clarification of the correct frame rate! 👍
DeleteWith that, and looking at the over-complex stuff I wrote (I'm terrible at editing myself), here's how I'd make a 1080p video as simply as possible. Without any scaling or editing, and using the original filenames created by C64emu:
Take PNG frames and generate an mp4 video file at 50.1245421245 frames per second, scaled 4x with sharp pixels (no smooth scaling):
> ffmpeg -framerate 50.1245421245 -i pngs\%10d.png -vf "scale=iw*4:ih*4" -sws_flags neighbor -sws_dither none -vcodec libx264 -preset slow -crf 10 bruce-lee_a-4xvid-501245fps-mute.mp4
Take mp4 video, stretch and scale to a 1440x1080 frame, perfect for old school 4:3 video on YouTube (think of setsar as resetting the aspect-ratio):
> ffmpeg -i bruce-lee_a-4xvid-501245fps-mute.mp4 -vf "scale=1440:1080,setsar=1" -sws_flags lanczos -sws_dither none -c:v libx264 -preset slow -crf 10 -r 50.1245421245 bruce-lee_b-1080vid-501245fps-mute.mp4
Check that the duration of everything was kept correct at each step:
> ffprobe pngs\audio.wav
(Duration: 00:14:57.72)
> ffprobe bruce-lee_a-4xvid-501245fps-mute.mp4
(Duration: 00:14:57.72)
> ffprobe bruce-lee_b-1080vid-501245fps-mute.mp4
(Duration: 00:14:57.72)
All good! :) So no speed adjust with SoX is needed, so just combine the audio and video:
> ffmpeg -i bruce-lee_b-1080vid-501245fps-mute.mp4 -i pngs\audio.wav -c:a aac -b:a 196k -ar 48000 -shortest -c:v copy brucelee_c-1080vid-50fps-aac-FINISH.mp4
-i specifies an input file
-c:a sets the paramaters of the audio (aac, 196kbit, 48000kHz)
-shortest sets the output file to be no longer than the shortest input file
(ie: any longer files get cut short to match)
-c:v sets the video parameters. Here it's just copied.
(in previous steps it was: lib264 video, slow compression, quality(crf) 10)
-r sets the frame rate. Often ffmpeg is smart at picking it from the source.
And here's the completed, unedited video:
https://www.youtube.com/watch?v=7pC21n9e1b4
(cracker intro starts at 1:28, game title music starts at 2:21)
Thanks for the appreciation of the gifs. It's really nice to have an emulator that makes it so easy to drop the frames into ScreenToGIF. 😊 ..If it's not too much to ask, could the frequency of the exported frames be configurable? Like export every frame or every 2nd frame, every 4th, every 8th, every 16th, every 32nd, maybe? I see they're often made by people as more as a fast slideshow: https://www.c64-wiki.com/wiki/Gold_Quest_VI
DeleteI think you might be right not to put too much effort into video export. Video formats are so darned complex. When OBS does it as well as it does, why try to compete? And its capture will include the temporal fade between frames, so it will look good on 60Hz displays, which is usually the frequency people view at, rather than 50.12454212Hz. 😊
I should i have posted here :) Something i noticed with demos is that non single file demos will result in the emulation hanging while launching the main executable after having loaded it into memory. Can you confirm this is a known limitation for the C64 floppy disk ? Because it really looks like all is ok with single file demos, but any demo made of many files is hanging after issuing the "run" command. Thanks ! By the way, the Sprites options as well as the borders options and also the debugging features are just Ace !
ReplyDeleteIt looks like i simply did not read the information you provided in first release sorry for that :/ Anyway best C64 emulator to me :)
DeleteTo keep the world in balance, I also use some redundancy, with a little content sensitivity ;)
DeleteNever mind, it's my fault that there's still no full 1541 emulation, which let's face it, would be expected from a C64 emulator in 2025 :)
But I'm working on it.
I'm really glad you like the emulator, and I hope it will soon be usable with more than just one-filers :)
P.S.: It's worth trying LFT's Nine with transparent sprites, you can see everything he explained in his secret-revealing video ;)
I already tested it with you first emulator version, was the very first thing i tested, and indeed that's just crazy how much information is visually provided when using sprite transparency, sprite numbers, borders transparency also :) Actually i think i was also misleaded by the just unbelievable state of your emulator that i implicitely thought 1541 emulation was also completed :) But anyway I'm now only using this one when it comes to onefile demos, and i will obviously switch from vice to it when it's features complete :)
DeleteBut you can wait forever for an emulator to be complete, if there is such a thing :D
DeleteAnyway, I'm really glad you like my emulator, I'm always very proud when someone has a happy moment using it! :)
First run resulted in a full lock up of my machine which required a power cycle to restore. I appreciate your efforts but I think you should do more testing before distributing a binary.
ReplyDeleteI'm sorry to hear that, but unfortunately I can only test it on my own machines, and I usually ask a few friends to test it for me as well. Other than that, I can only rely on user feedback, which is still quite limited, as I launched the emulator just over a month ago.
DeletePlease tell me your system specifications (CPU, GPU, amount of RAM, which OS version you tried it on) and I will investigate what might have caused the problem!
Thank you for helping me with your feedback!