R0ger

Haha, nice ! Knowing about the thread could save me some time. Or probable I would just do something else, because initially I thought it would be lot easier. Btw. concerning the Easter egg .. even without hacking, there are already clues about it in this thread ! Don't give up

Btw. have anyone found the Easter egg in the scroller yet ?

It's close to some other parties, and my time is limited, but I'm seriously considering it

Don't overthink it Fingolfin. Everybody is happy and thankful. Both authors and consumers. Just not many express it as much as you do. There are many secluded communities inside our Atari family, Czechs, Poles, Germans .. mostly the language barrier is to blame. Some people from FLOP team don't even have account here, or don't visit often. But don't worry, I'll convey all reaction on our weekly meeting :-) And I'm especially sure PG doesn't take anything in a bad way, not his nature really ..

I did 30 minutes talk about the scroller, but it's kinda information dense and I don't feel like subtitling it all. So maybe I just put some info here .. The basic idea is to scroll the image up as usual, but to remove 2 pixel on every line, so the new line is 1 pixel shorter from both sides. The first problem is to choose the right pixels. It has to be done uniformly, you must not remove near pixels in successive lines. I also tried to make it so that when 50% of the pixels are removed, it's exactly every second pixel, so the font is kept readable as long as possible. I need to remove 1 pixel each line in both left and right half. I use recursive approach for pixel selection. If I use decimal position along the line, the positions would go like this: 0.5 | 0.25 0.75 | 0.125 0.625 0.375 0.875 and so on. You can treat the sequence as binary tree, 0.5 being the root, 0.25 and .75 being first level and so on. Like this you can compute now values as parent/2 and parent/2+0.5. Another problem is you have follow the original pixels as they keep changing positions, so in the end the code to pick the pixels was surprisingly complex, but whatever, it works. This code was written outside Atari code, in VB6 (still my favorite for small stuff), and it outputs macro calls with parameters at what bytes and at what bit the pixel should be removed. The macros are then expanded into one huge unlooped code block, which does the transformation. Next is the problem of speed. To correctly do the perspective transformation, the scroller needs to slow down as the texture is getting away from you, and the texture has to get denser. First I tried just dividing the scroller into 3 zones, the top zone being scrolled at 50% speed, and the middle at 75% speed. At the boundaries the extra pixel lines got lost, and it looked kinda OK. But once the pixel line was gone, it was gone for good, you could see the transition, and I wasn't too happy about it. So in the end I used different approach. There are invisible lines in the picture. On the bottom there are none, but they are inserted and getting denser. On the top there is several invisible lines for every visible line. This allowed me to change the speed gradually and actually not loose any data. This however brought another problem. The code was too slow and large. So there is another trick. I only use the code make the line narrower, in-place. To remove the 2 pixels. But to scroll it up, or to hide the line, I just use display list. Only rows which end up visible on the screen must be narrowed, and on average only half of the bytes has to be touched. Lines which are hidden don't have to be processed at all, just their address is removed from display list. This shortened the code and made it all lot faster. The VB6 just generates a bit more complex macros list, like this: ScaleLine -79 139 19 3 21 0 17 ScrollLine -78 -79 ScrollLine -77 -78 ScrollLine 138 -77 ScaleLine -76 138 18 7 20 3 17 ScrollLine -75 -76 ScaleLine takes arguments: source line, destination line, byte/bit to remove, byte/bit to remove, and number of bytes from both sides I don't have to process (this is the narrowest part, hence 17 out of 20 is not processed). ScrollLine just takes source line and destination line. Whenever the line index is negative, it means invisible line in temporary list, when it's positive, it's line in the display list. In the final version I even brought back the zone approach to speed .. the top third of the scroller is refreshed less often, for better speed, less transformation code, and less invisible lines. There are other minor problems I talked about, but this is the core of the problem. The video is here, but it's really poor quality, sorry about that .. Some interesting time points: 1:38 - I talk about different approach in some C64 demo .. boring 12:05 - random pixel picking demonstration 13:20 - recursive pixel picking demonstration 16:29 - demonstration of how exactly every 2nd pixel is removed first 18:11 - early version of the scroller, zone based slow down 18:28 - taller version, still zone based, but first version of in-place transformation and display list based scrolling up 20:25 - demonstration which shows hidden lines of the image

Thanks for kind words, it means a lot for the team. Glad to see it was worth the trouble ! :-) This year was though, not only we decided to include English version, but also the team changed. The main editor used to be Fandal, as if he wasn't doing enough for the scene already. Changing the team AND expanding to English at the same time proved to be bad idea, but in the end we made it. But we learned a lot and we hope next issue will go smoother.

We left out PG in the credits ! At least he's in credit for the intro, but not for the magazine .. well ..

Funny thing. Had no idea what SAP Type R is .. went to work on my new game, and had to record video from emulator, as I'm not sure about bug in animation .. and there it is, in the record menu of Altirra. So now it makes sense !

Would be nice to have some memory writes dump from emulator .. you would be able to filter for Pokey writes and sort it all out.

That's ok. In Input>port1 there are only mappings for port1. You are using multijoy, which in Altirra is like completely different port. It's doesn't have to show in the menu. The menu is just shortcut for quick changing the input maps. Just use the setup as in the picture above, make sure it's checked in the 'Input maps'. Boot some game with multijoy support and test it.

Haha .. the different cars for different goods is nice touch

What do you mean 'no case' ? Looks good to me. Doesn't it work ?

You need to add joystick in port Multijoy#1 .. then another joystick in port Multijoy#2 and so on .. you then active all these mapping at once. Also don't forget to disable any mapping for regular joystick ports.

What do you mean, PAST loyalties ? That's treason !

Looks good to me. Of course like this you have duplicate label wait, but I guess it's just for demonstration. Also just like this you don't need lda #1,asl,asl,asl,asl, you can just do lda #$10. But most of the time you do it in loop, so you have the asl in there. The wait is important, besides that, there is no trick. Also multijoy is fully supported in Altirra, so don't be afraid to simply try it.

Thanks for thanks I guess :-) But what do the colors mean !?

Guys plz .. get a room. By which I mean thread.

Sorry to disappoint. I said 'minor'. It's just an intro for our discmag. It's not like the intro is not cool though .. The discmag used to be Czech only, so NTSC was not an issue. We're trying to include English articles this time, so even if some of the binary entries might not be NTSC compatible, it would be nice if at least the intro and the text reader was compatible.

Btw. I would need someone to test some minor piece of software on real hardware NTSC. Somebody who is online often, and is really willing to do it. I will bother you. You'll be sorry in the end. Ideally someone who can test both CRT and LCD. I will also want photos of the screen so I can compare the colors. I offer nothing. Possibly mention in credits. Also under strict NDA, as it's supposed to be surprise, right ? Ps. not you emkay. Sorry but you English is sometimes way hard to understand

Guys. Let's not get into C64 vs. Atari debate here. Not because it's off-topic. This is C64 conversion after all. Comparisons are expected. But with conversion like this, it's just cruel to C64 owners. You have to understand. You have to support them, they are going through some hard times. It's not their fault their mom both them the thing 30 years ago instead of real computer.

HM .. ok .. I understand. Might be useful sometimes. It's basically the same issue as screen flicker, just in audio :-)

Indeed. I'm not used to 50 Hz flicker anymore either. But it's the age of LCDs. Flicker is not an issue.

How is sound on NTSC machine better ?

Hello. We started PAL/NTSC conversation in Stunt car racer. I admired how the conversion supports both PAL and NTSC, and I called NTSC damn and clunky. To which MrFish reacted: What's all this crap about how bad NTSC is compared to PAL? The vast majority of software that's been written for the system relies on refresh speed and is thus faster on NTSC than PAL. To which I reacted: For games doing things between frames, there is 20% less time between frames. For games doing things independent of frames (like this one), there is less time, as ATARI has to draw 60 frames per second instead of 50, and there is more DMA. OF course considering the graphics are the same in both versions, but that is usually the case. Also all VBI and DLI code is called 20% more often, giving you less time for the rest. Add different style of artifacting, and the fact that as I mentioned, you have to limit graphic to NTSC size, I'm surprised there even are games and demos which work on both. I value such achievement highly. To which _The Doctor__ reacted: Yes true to a point, but the NTSC clock is also faster so more cycles in the given period minus the 5 doubled frames... And MrFish reacted: There are a multitude of cases where having more time in the VBlank does nothing to help PAL systems keep up with NTSC's +20% screen refresh speed advantage. So, you favor what PAL systems have to offer; is it necessary to denigrate NTSC systems in order to express it? And here I'm starting new thread, not to derail the original thread any more. ------ To the argument that NTSC has faster CPU I say this. Yes. It's about 1% faster. But considering it has to draw 20% more frames, it doesn't help much. And to MrFish I say: Yes, in every compatible game there is nothing the PAL version can do in the extra time it gains. Because it wouldn't be able to do it on NTSC version. You have to adjust what the game does to the limit, which is imposed by NTSC. PAL can do 20% more. Of course, at the price of lower FPS. But NTSC software will run on PAL, albeit slower. PAL software won't necessarily run on NTSC. And my intention is not to denigrate anything. It's just how the things are. As a developer I see NTSC as extra limit. I'm not happy about it. But denigrate ? Cheer up man. Which leads me to question .. in experience of NTSC user .. how much software is not NTSC compatible ? I guess old commercial software is all NTSC compatible, most of it was created in USA anyway. But considering how much Atari is popular in Europe, I imagine some of the new stuff is not. Especially demos. I wouldn't know, I typically don't try to run stuff on NTSC, and if it is mentioned in release notes, I ignore it, as I don't need the information.

For games doing things between frames, there is 20% less time between frames. For games doing things independent of frames (like this one), there is less time, as ATARI has to draw 60 frames per second instead of 50, and there is more DMA. OF course considering the graphics are the same in both versions, but that is usually the case. Also all VBI and DLI code is called 20% more often, giving you less time for the rest. Add different style of artifacting, and the fact that as I mentioned, you have to limit graphic to NTSC size, I'm surprised there even are games and demos which work on both. I value such achievement highly.