R0ger

Kinda late for the thread. I can't much help with filling. Never done that. But I have game oriented wire-frame engine. (related thread here: http://atariage.com/forums/topic/237244-rescue-3d-engine-demo) By game oriented I mean it has relatively few limitations. The matrices are 8 bit, positions 16 bit, this is transformed into 16bit, where clipping and persp is done. Lines are Bressenham with unrolled 16 cases (all combinations of up-left / left for 4 bits) (http://atariage.com/forums/topic/231690-known-fast-line-algorithms). I plan to replace with something simpler, the line makes under 15%, so it does not justify the complexity of the routine. There is still lot of time for improvement, it's one of the first 6502 codes I've done. For my purposes (space game, one day, maybe ?) filling doesn't seem important. I will take framerate over it every time. Also the engine also supports red-cyan 3D mode, with like 15% price. All math is the same, simple Z-based table is used for paralax, just the lines have to be done twice. It actually looks quite good, and it works better with transparent objects.

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.

I plan to do XEX version which would load the data into RAM first, but don't expect it very soon.

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

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 It still looks decent. Also thanks to Nezgar for testing ! BadApple.1.1.NTSC.zip

Well I do it because I can't handle the harsh DMA on NTSC .. but it sounds better if I say it's because of correct aspect ratio, right ?

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.

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 ..

Thanks for kind words 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.

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 ..

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.

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

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 !

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.

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

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.

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.

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 ..

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

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

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.

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.

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 ..

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. 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) ..

Oh no .. guys are angry at me ! I forgot to mention the demo was released (ie finished, tested, and fixed) during Platariada party ! http://pl.atariada.cz