Xuel
-
Posts
849 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Xuel
-
-
Would it be possible that some compiled executables can be added to GitHub? We've not all got the setup on our computers to be able to compile this code correctly and it'd be nice if there was one place (other than here spread over several pages) where we can find the different versions. It'd be nice if the different OS versions were in there too.
I wouldn't mind testing it out on my Linux BeagleBone with maxevals enabled. Then I'd set up a batch run and see what comes out!
I added my latest Windows and Linux x64 builds to the downloads area. Can you provide a Beaglebone ARM build?
-
1
-
-
The GitHub repository is here:
https://github.com/i...RastaConverter/
Empty for now - I'm out of time today to do it.
Xuel, you should have access to add a version with your modifications now.
Thanks! I pushed a bunch of commits. I tried to recreate the commit history leading up to Rasta-opthack5. I'll add branches from other folks soon.
-
I found that I can "fix" the top border by simply patching rasta.cpp so that it never mutates the COLBAK initial register value away from zero. No need for additional instruction shuffling because Rasta will naturally figure it out from there.
This zip file contains a recompiled version of Rasta-opthack5 with this border fix. It also includes a patched version of no_name.asq that adds the missile borders on the left and right of the image. Although counter-intuitive, this lets you use the /noborder mode to use all four players for detail while still getting a nice border. You can unzip this over your existing rasta work area at your own risk.
Here is Emkay's dumm.xex with borders. It doesn't include the new top-border fix, but rather my old top-border fix that corrupts some of the top lines.
ilmenit, do you plan on putting your code into a revision control repository, e.g. github? You could then field pull requests as you see fit. And, BTW, thanks for making this code available to all of us!
-
1
-
-
Some hacks to improve borders:
- Skip COLBAK init to improve top border.
- Use all four missiles with PF3 (fifth player) for side borders, disable GRACTL missile DMA, set GRAFM to $FF. This allows using /noborder mode in RastaConverter so all four players can be used for detail.
Do you modify the source of RastaConverter too? I'm planning to do some changes now and would like to work on the newest version.
I have to read about how setting GRAFM=$FF and no missile DMA covers other players.
How skipping the COLBAK init can improve the top border?
No, the only modification I made was to add a /max_evals flag. (And I'm not sure I did it right since I don't know if 999,999,999 always fits in an unsigned.)
I implemented the missile borders in movie.asq. See also PRIOR and GRAFM in phaeron's manual.
You have to enable extended PAL height in Altirra to see the top-border artifacts caused by initializing COLBAK too soon. I implemented the top-border fixes as post-processing filters in the Makefile.
perl -ne 'print if /Init/ .. /ldy/; print if /line0/ .. /line160/' \ $*.out.png.rp.ini $*.out.png.rp \ | perl -e '@l=<>;splice@l,25,0,splice(@l,7,2),splice@l,23,1;print@l' \ | perl -pe '0 if 1 .. s/COLBAK/HITCLR/' \
The first perl hack strips out the sync stuff from the rp.ini. I moved all the sync to movie.asq. The second perl hack shuffles the STA COLBAK as late as possible, but it was still visible. So the third perl hack disables the STA COLBAK altogether. I don't like this because it can really mess up some pictures that don't change COLBAK for a long time. I was going to experiment with a more complicated filter that can look for useless instructions in the first line that it can overwrite with the COLBAK init, or do some other sort of instruction shuffling.
leenorris.xex - Nice
It may be worth to try to do transitions from one frame to the next using the /continue option. In theory it could minimize raster program differences caused by random initialization and animation could be smoother. Maybe another parameter /transform (instead of /continue) should be added to change probability of mutations or use different mutations.Cool idea! I'll try with /continue. So, with /transform it would basically be like giving RastaConverter a strong hint about where to start but still giving it freedom to make some significant changes as though you were starting from scratch? Very nice. Maybe it would make sense to use /transform for P and B-frames and start from scratch or bump the mutation probability way up for I-frames?
- Skip COLBAK init to improve top border.
-
Emkay, here is your picture with the border hacks applied:
Notice that the antenna in the top left suffers from not init'ing COLBAK. I am thinking about more reordering hacks to push the COLBAK init forward into the first line instead of not doing it at all.
-
1
-
-
Some hacks to improve borders:
- Skip COLBAK init to improve top border.
- Use all four missiles with PF3 (fifth player) for side borders, disable GRACTL missile DMA, set GRAFM to $FF. This allows using /noborder mode in RastaConverter so all four players can be used for detail.
-
1
- Skip COLBAK init to improve top border.
-
All I/O is by the CPU (no DMA devices), so you can put the data anywhere.
The IDE types can do adhoc I/O so you don't get overrun problems like with SIO.
I can give it a try. Which of Altirra's disk emulations would you recommend? I found the MyIDE docs which look simple enough.
-
Can't the movie be streamed from a hard disk? Modern interfaces are providing 65kb/s - almost as fast as the A8 can read from RAM.
Possibly, but the raster program eats a lot CPU, so there wouldn't be much left over for disk handling. You could probably do a movie that covers a small part of the screen at least. Is there any disk hardware that can memory map its own 16K-32K buffer into system RAM space? If you could tightly control the timing of when the drive fills this buffer, then we could get full screen.
-
Yea, the borders were very messed up there. Release early, release often!
The frames have to fit into 16K banks, so that's why the bottoms have to be cut off.
Here's a new version with cleaned up borders. I also reran RastaConverter with 3M evaluations per frame instead of only 100K.
As AtariNerd says, I saw what Crest did with NUFLI and NuvieMaker (examples) and thought it would be the next logical step for RastaConverter. Now we just need a really huge memory expansion. Is there anything over 1088K?
On Github:
-
1
-
-
-
3
-
-
It doesn't really matter, because of the DMA reads spread on the right half of the screen. What's more important is to add an 48 byte mode, to get the border unicolour, when all PM is used, which helps to add more colours there.
I agree. That would be cool.
-
I noticed that the display list that RastaConverter generates uses LMS instructions for every line. Those eat 2 cycles for DMA every line. Could another LDA/X/Y could be squeezed in if those are removed?
Another cycle could be saved if missile DMA is disabled. So, using emkay's scheme that should be enough for another STA/X/Y as well, since 3 extra cycles + 1 = 4 = cycles per STA/X/Y.
-
-
Crest debuted NUFLI in their Crest Slide Story 90% demo.
They also released a NUFLI Editor. Here are versions 1.11 and 1.22.
-
Pretty cool! Nice little music routine.
-
(3, 4 and G2F-file next week)
Great tutorial! I look forward to the next installments.
-
I took a whack at redoing the audio code, so if you're bothered by the variation, try 1.8-test4. I don't recommend DirectSound mode as it will repeat whenever the emulator has UI up, but it does have shorter latency and works better under Vista. You can now adjust the buffering.
Very nice! To my ear, it sounds like you've completely eliminated the variation. Excellent enhancement!
-
That label looks rather nice. Did you make it yourself?
Mine came the same way, so I suspect it's ctirad's design.
-
-
3b@ emkay, which of the latest tunes is the best to make another recording of?Thanks in advance.
Just wanted to say that this tune rocks! I've been listening to it a lot lately. Great work emkay.
-
Yes it would be nice to see this fixed in the next build. I figured this was on the to do list?Altirra has probs with the replaying speed.... it gets faster and slower . In german terms : es leiert ... means "it's droning"Yea, the audio wow is really noticeable. Luckily it seems to be an artifact of playback and not the simulation because if you save a video, the wow is gone. That leads me to believe that the simulator is keeping the Pokey and CPU in lock step in an abstract non-real-time sense. But then the playback engine decides to constantly vary the physical sampling frequency in order to sync with the rate that simulation frames are becoming available. I'm not sure why Phaeron choose this approach. It seems like a sufficient buffer would solve the problem. But maybe the point is to sacrifice even sampling for lower input latency which would be helpful for twitch-style gaming?
-
Wow, looks like the old versions of Altirra work now too. Must have been some update to Wine that did it. Well, thanks to Wine too!
Awesome! This version works under Ubuntu/Wine for me. Thanks Phaeron!
-
Awesome! This version works under Ubuntu/Wine for me. Thanks Phaeron!
-
Yea, that would definitely look prettier, but just for fun, I'm trying to avoid making any permanent modifications to this system. We'll see how long I can hold out.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Quantizator
in Atari 8-Bit Computers
Posted
I was thinking the same thing! I created a fork that makes Allegro optional. Executables here. I made the default /max_evals=5000 when Allegro is disabled.
ilmenit, I hesitate to merge this into the mainline since it mucks up the code quite a bit. Ideas?