Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

R0ger

Members
 View Profile  See their activity

  • Content Count

    753

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by R0ger

  1. Posted

    Hm .. more ROM wouldn't help. Unless you go full uncompressed and Atari CPU does nothing. In that case everything is easy and you can play 256 color video at 50/60 fps.

    But I think my RLE decompression is pretty close to what's possible. At 256x96. And that's like the easiest possible and simple to optimize compression. I can go 256x192, but at lets say 7fps. That seems too choppy for me. And it wouldn't even need more ROM - as it will have less frames. Atari certainly can't do what Sega does. And who know if the Sega version uses Sega CPU.

    • Like 1

  3. Posted

     

    Thank's man...

    Is there any way to get rid of the song from my head?

     

    It's impossible to get rid of a song in your head .. you can only replace it with different viral song .. for sake of this not changing into viral song contest, I am not including my choices :-D

    • Like 1

  4. Posted · Edited by R0ger

    So here is the NTSC version. The resolution is lowered to 256x80, same 12.5FPS, colors in the credits picture are shifted, music is the same, interpolated to 50Hz. Also the final picture is the same, so it does not fit the last frame of the video the way it does on PAL version .. but it took like week to make that picture, I'm not redrawing it, sorry :-D It still looks decent.

     

    Also thanks to Nezgar for testing !

    BadApple.1.1.NTSC.zip

    • Like 10

  6. Posted

    Noticed another quite important thing .. which kinda makes sense .. NTSC has (obviously) quite different pixel aspect ratio .. so showing the animation in the original resolution is simply wrong. So I guess I will go this way:

    1) render the video in lower resolution - 256x80 (compared to 256x96)

    2) have completely different standalone NTSC version - no need to detect & switch, and it will be easier to fix the colors in the credits picture.

    3) framerate wil be the same, 12.5 fps avg, music will be the same, slowed down by 6/5 rule.

  7. Posted · Edited by R0ger

    Hm .. did the frame skip .. and it looks worse than I expected .. it's right out ugly.

    I tried decreasing image height .. it's simple to do .. but I only manage to 'make it' at like 80 lines .. the PAL version has 96. That is 6/5 ratio, but I should be able to manage more that that !

    The decoding code does not depend on the video system at all .. music playing, frame sync should be the same as the PAL version, it's not called every 6th frame.

    So the only overhead is some DMA and extra DLI a VBI calls, which do only small things.

    Any idea where the cycles go ?

     

    Edit: did some altirra profiling .. DMA seems to be main culprit .. the decoding routine DMA penalty increases from 24% to 34% from PAL to NTSC .. have to try some more stuff ..

  8. Posted

    Thanks for kind words :P

     

    Anyway .. I changed the synchronization code, so it's handles better the cases, where it fails to render frames in time. It's allowed to lag behind and catch up later.

    It only happens with NTSC and with filled drawing mode. NTSC does not involve that much overhead code, but there is some, and the thing is, there is basically no reserve in the filled mode. Scanlines are fine even under NTSC, because on those empty lines DMA does not steal cycles.

     

    So .. it works .. but the section with slower frames is kinda long, and the lag can get as bad as 20 frames .. so I wanna try to implement frame-skip feature .. when the lag will be more then 1 full frame, I will skip a frame in decoder .. that will require to have some information about frame length in the data, but I still have lot of space.

  9. Posted

    600lxl 64k with Monitor port NTSC, HDMI Upscaler, Lotharek Stereo, Atarimax 8mb cart : There are tiny screen jumps, running in scanline mode is better, and it is faster, of course. It Quits right before credit screen.

    800xl U1mb, Stereo, HDMI Upscaler, PAL Antic, PAL Gtia, NTSC Crystal : Everything cool, no timing issues. A - OK.

     

    Yes, it's because of the NTSC, as I said, the current version does not take that into account at all. It's miracle it almost works .. but be patient, I'm working on the NTSC support ..

    • Like 1

  10. Posted

    Interesting. Thanks. That packing is more efficient than flash pack which can decompress 30kb/s?

     

    No idea. Mine has to do 38.4kb/s (12.5x32x96) .. it manages up to twice as fast in simple frames. And that's including doing it by columns, which is good for compression ratio.

    • Like 3

  11. Posted · Edited by R0ger

    Roger... excellent... any technical details in terms of packer etc?

     

    It's quite simple RLE .. but it's written from scratch and tuned to the data, after trying several different approaches. It had to be fast to decompress first, but as good as possible compression second.

    Works like this:

    - data are packed by the byte wide columns, from top to bottom, then columns from left to right ..

    - consecutive bytes are xored .. so if you have same bytes above eachother, you get zeros in the stream

    - this stream is then RLE coded like this: first there is control byte, which says how many zero bytes and how many data bytes there is. In this byte 5 times more space is allocated for the zeros, the formula is zero_count*5+data_count, with max 50 zero bytes or 5 data bytes for 1 control byte. Both cases with 0 zero bytes and 0 data bytes are used when needed.

    This 5 is one of the parameters of the coder, and has been found as optimal for the data.

    - after the control byte there are the data bytes .. zeros are obviously filled just by the count

    - for simplicity (ie speed) of the decoder, there is always control byte at the column break, so I don't have to check for column end when I process the data group. I only have to check the new column after data group, before new control byte.

    - decompression implementation detail .. it is all done in linear zero page buffer, 96 bytes long. After the column is decompressed, it's flushed into the VRAM using typical unlooped xor filler

    - also at the beginning of each frame there are also 2 bytes describing how many columns from left and right are completely of one color, and if it is black or white .. this border cut-off saves like 10% of the data.

    - there are some other minor details, but this is the basics

    • Like 3

  12. Posted

    So, NTSC guys, rejoice. I couldn't resist and did some very basic 'ignore every 6th' code for both music and frame swapping. And it works ! Still lot of work, like detection, and I have to rearrange some things as I run out of the space in the bank I have the main code in.

    But it works, at correct speed, with full synchronization. I think I can sometimes hear the glitch in the audio, but it's very subtle, doubt anyone else will notice it.

    Also I will need someone with NTSC machine for testing !

    • Like 5

  13. Posted

    I will certainly try to make it work under NTSC, so far it looks doable. At correct speed if possible. I also want to take a look at those English lyrics, though I can see several problem with that .. the verses would have to be organized in same way and fit into 40 character. And let me tell you, timing it was bitch, and it would have to be done again. So only if all goes super smooth.

    Still don't expect new version right away. Hove some other stuff to do atm and also I don't want to have 10 version flying around. 2 are passable.

    • Like 1

  14. Posted

    As you probably know too well the problem with NTSC for such demos as this is the available cycles per frame is so much fewer. If double-buffering is in use and the Pal version was dropping occasional frames anyway then it's probably not much concern.

    Music - not so hard as you'd think. You can skip RMT processing every 6th frame which will preserve the speed. But of course if the music needs to be synced with events in the video sequence then it gets a bit more complex.

     

    I believe such crude approximation would be noticeable .. will try anyway, have some similar ideas ..

  15. Posted

    It's very simple. The demo is not intended for NTSC at all. I can try to make it work. It will have to be faster though (20%), the main problem for timing is the music, it's tied to VBI, and it's can't be easily changed.

     

    I can move the image up so the lyrics fit. I can redo the synchronization code to be more flexible, to allow the video to lag behind. There are only few sections, which really get near limit.

    • Like 1

  16. Posted

    Antic B tested also? And, ofcourse, if you use lower resolutions, fullscreen use is recommended (160x120)

     

    Nah .. just not worth it .. I went for resolution first, framerate later. But 256x192 or even 320x240 would be way to slow to even be an animation .. 256x96 at 12.5 fps seems like best compromise.

  17. Posted · Edited by R0ger

    Is it allowed to have a look in the RMT ? What patches did you use?

     

    I don't know about how the Data has to be converted from the original to your version. But could it be possible to use Antic D in fullscreen without a huge amount of "rework" ? It either could result in the double of used frames or RMT could be used at 3 or even 4 times replay speed.

    As for RMT patch, I tried some, but made my own in the end. Basically RMT A mode is tuned to 440Hz more or less. C and E are bit higher though. So I shifted A mode so it's better in tune with C and E. Still it's not universally usable, the 8 bit bass modes are way off.

     

    The D mode is actually good idea .. I wanted to go 256 in width, to preserve as much detail as possible .. and it wouldn't be 3 times faster .. but it could pretty well be 2 times faster, which is all I would ever ask for .. will think about it ..

     

    Edit: Did quick compression test .. at 128x96, 25FPS it takes 1.133 meg .. in other words it does not compress as well, which is to be expected. And it doesn't look that much good either .. so I guess I'm not even trying to modify the playback on Atari ..

  18. Posted

    Unsure what you mean "all Japanese" but since you mentioned anime girls I guess you mean anime and manga and possibly games with anime styled graphics

    I learn Japanese, I visit Japan every year, I even climbed Fuji .. in other words fully developed Japanophilia ..

    • Like 3

  19. Posted · Edited by R0ger

    my little ATASCII test of the notorious video enclosed. might not work on the real deal, have no atari on me :( This is because many (too many?) lines used to keep the original (?) video ratio.

    requires hard disk or something, reading with floppy speed not advised :]

    start with "X BAD.XEX" on SDX, but possibly it is cool to run it from e.g. SIDE.

     

    it starts with some apparently blank screens, but it is just the video as it is.

     

    the goal of the experiment was to check whether it is possible at all to see anything in ATASCII animated. experiment was a success : ]

     

    Wanna see it ! But can't make the xex work (in Altirra) .. any chance you can upload it on youtube ?

  20. Posted

    Well, I wrote that after a short view over the video. Forget that part ;)

     

     

     

    Nice effort. But, as it seems, it's not my kind of music, added with the typical POKEY 8-bit detune that keeps me distant...

    But it sounds much better than the "other" version.

     

    I see .. well yeah .. I spent like half of the time writing the tracks, fiddling with instruments, adjusting volumes, deciding channel allocation, all that jazz .. and the other half I spent researching limits and options of how the get the damn thing in tune. The demo actually uses modified freq tables for RMT for the lead voices. But I'm not sure it helps much. One day it seems like it helps a lot, other day I can't tell the difference.

  21. Posted

    Looks nice. The only thing I noticed is that my screen turns green just as she throws the knife. If I press L it fixes the screen. I must press L again because the lyrics make my Sharp Aquos monitor go crazy and vertically 'flip' a lot. This is the same monitor that supports NTSC, PAL, PAL60, but NOT NTSC50!

     

    The green problem has nothing to do with the monitor, of course.

     

    I am running it from an Ultimate cart on an Incognito 800 in 1088XE mode.

     

    Edit: With 65c802 CPU.

    Probably some problem with timing. There is code in the demo which turns screen yellow when it fails to render frame in time. It might come out as greenish on some devices .. I was thinking about some softer approach, but real Atari and proper emulators have no problem with timing being precise enough. And as for lyrics, it's simply because they use more then 200 lines. That's still totally legal, but some emulators or monitors can have trouble with that.

  22. Posted · Edited by R0ger

    Now that we have two times the "Bad Apple", I wonder when we get a nice version of this:

     

    Nice. Good to see other Touhou fans (possibly) here.

     

    I'm fan of all Japanese in general, but not really especially Touhou inclined. Just like this video and the associated remakes. I even held 1 hour lecture about history of it on this year's Atariada, it's on youtube, in Czech only though. As for other videos .. first .. I'm not making any more for some time now I guess .. second .. unless it has cute anime girls, forget it .. :-D

  23. Posted

    If using Stereo, why not using a 16 bit channel for the main melodic voice?

    I felt it's not needed. The music actually uses slightly modified freq tables in RMT. In the end I found the lead to be ok just like this. The bass line in one channel uses 16bit. The lead has 2 different voices, and I came to conclusion that I need base drum in both channels to get that dancy feeling of the original. So I didn't really have channels to spare.

     

    How about some challenge? Using no black "scanlines" and to optimize the tune for one POKEY ? Saving some CPU for the music? Using the vertical scrolling could help to remove the scanlines... ;)

     

    Not sure I follow. There is mono version .. it plays when you have Atari with single POKEY.

     

    Using no black lines ? There's option for that.

    As for playing the video in full 256x192, that would only be possible at halve the framerate. I prefer this combination. I don't think there is much room for improving playback speed. I can play some of the frames at 25fps .. but the overall framerate is defined by the slowest frames. Which I know can do at 12.5 fps. Of course, there could be variable framerate .. but then I don't really have that much room to store more frames, and it would complicate synchronization with the music, which I think is important for music video (and sadly not often achieved in 8-bit remakes).

     

    Saving some CPU for the music? Music takes 15% of the time, which I consider way too much. There are 2 RMT calls per frame to achieve tricky 5.5 frames per line .. it also helps with instruments. The resulting speed is 136.36 BPM .. which is 2% slower then the original 138 BPM. The video is then slowed accordingly to match the music. That's pretty unnoticeable difference unless you play it side by side.

     

    Using the vertical scrolling could help to remove the scanlines ? What ? How ? Also .. why ? I love the scanlines (on CRT) ..

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...