analmux Posted October 21, 2009 Share Posted October 21, 2009 I see you still don't like me and it's your right. Sorry if I wasn't clear. I don't like Rockford, I love it, ah I adore my new god. 1 Link to comment Share on other sites More sharing options...
emkay Posted October 21, 2009 Share Posted October 21, 2009 All you're doing by speeding up VICE is fast forwarding the C64 like you would a DVD, all the frames are still there but you're being shown less of them to generate the effect that time is passing faster. You really believe that? You know that a PC of today is about several million times faster than the C64 ? When you turn Vice to double speed ALL is running at double speed. And when playing a game -- using sprites-- it is working at full frames, it is even doubled , and clean.... not jumpy, just fluent... Link to comment Share on other sites More sharing options...
emkay Posted October 21, 2009 Share Posted October 21, 2009 that definitly looks like RoFL... and reminds me to dig out my A1200 to watch all the lovely demos again... Interesting. The framerate is good, but the screen is that small? In a demo? Done by sceners? Link to comment Share on other sites More sharing options...
emkay Posted October 21, 2009 Share Posted October 21, 2009 reminds me where the hell is my winua... but heck... I am on mac now... that's the reason I can not find it here... Selber schuld Link to comment Share on other sites More sharing options...
TMR Posted October 21, 2009 Share Posted October 21, 2009 All you're doing by speeding up VICE is fast forwarding the C64 like you would a DVD, all the frames are still there but you're being shown less of them to generate the effect that time is passing faster. You really believe that? Yes i do, because that's exactly what is happening; if it wasn't the case, with VICE at 200% speed there would be 126 cycles on most scanlines instead of the usual 63 and every single loop-timed event wouldn't work correctly, a doubling of speed on each scanline would break them badly because there's no WSYNC to catch and fix that on the C64. We're talking about simple things like raster bars on crack intros to far more complex timings such as the cycle precise ones used in demos for sideborder work. When you turn Vice to double speed ALL is running at double speed. And when playing a game -- using sprites-- it is working at full frames, it is even doubled , and clean.... not jumpy, just fluent... Without knowing which titles you're referring to it's hard to be specific, but generally speaking with 2D games that jumpiness will have been caused by the emulation and not visible on a real C64 - most 2D games on the C64 run at a close to rock solid 50FPS. Link to comment Share on other sites More sharing options...
Irgendwer Posted October 21, 2009 Share Posted October 21, 2009 I see you still don't like me and it's your right. It's fine with me but the problem is that all the time you just wait for opportunity to stab me in the back. Here is your another chance and you don't even hesitate. If you were a fair person you would read (or at least tried to read) the discussion that led to my decision. You see, I have nothing against fierce discussion (even some banter) or different opinions, but if somebody accuses you of something and then you patiently and politely explain it to him and next, shortly after you explanation, he repeats the same rubbish over and over again, the discussion ends right here, because it's an utter waste of time. SIMPLE AS THAT. So I have to ask you again, could you please cut that "god" crap and give me a break. I would be very grateful for that. Thank you in advance ! I know what you mean and I'm familar with this feeling too! My condolences. Link to comment Share on other sites More sharing options...
Irgendwer Posted October 21, 2009 Share Posted October 21, 2009 When you turn Vice to double speed ALL is running at double speed. And when playing a game -- using sprites-- it is working at full frames, it is even doubled , and clean.... not jumpy, just fluent... No, what TMR means is, that if the C64 version was programmed with e.g. a more rough movement in bigger steps due to limited processing power, speeding up the emulation would not help to get a more fluent movement. It still is rough, but of course faster. Link to comment Share on other sites More sharing options...
roland p Posted October 21, 2009 Share Posted October 21, 2009 All you're doing by speeding up VICE is fast forwarding the C64 like you would a DVD, all the frames are still there but you're being shown less of them to generate the effect that time is passing faster. You really believe that? You know that a PC of today is about several million times faster than the C64 ? The framerate of your pc doesn't increase, if you run an ntsc c64 at double speed, it produces 120Hz and frames will be dropped (assuming the screenupdate is locked to the vsync of your videocard) unless your videocard runs at 120Hz. If the emulator does not lock to the vsync of your video card, and writes 120fps you would see tearing. Link to comment Share on other sites More sharing options...
Shaun.Bebbington Posted October 21, 2009 Share Posted October 21, 2009 (edited) All you're doing by speeding up VICE is fast forwarding the C64 like you would a DVD, all the frames are still there but you're being shown less of them to generate the effect that time is passing faster. You really believe that? Yes i do, because that's exactly what is happening; if it wasn't the case, with VICE at 200% speed there would be 126 cycles on most scanlines instead of the usual 63 and every single loop-timed event wouldn't work correctly, a doubling of speed on each scanline would break them badly because there's no WSYNC to catch and fix that on the C64. We're talking about simple things like raster bars on crack intros to far more complex timings such as the cycle precise ones used in demos for sideborder work. I think TMR has a point here. I own a SuperCPU, which has a 20Mhz 65816 chip inside, and runs the C64 (or C64 mode on the 128) at either 20Mhz or 1Mhz depending on the selection switch (you can switch between the two modes in BASIC or ML too by writing to a certain register). Many demo effects screw up at 20Mhz becuase the computer now has around 20x more cycles per scan-line than in 1Mhz mode, so any code that requires cycle-exact timing doesn't work, or at least it doesn't have the desired effect. Yet this doesn't happen in VICE when speeded up. Regards, Shaun. Edited October 21, 2009 by Shaun.Bebbington Link to comment Share on other sites More sharing options...
emkay Posted October 21, 2009 Share Posted October 21, 2009 (edited) The framerate of your pc doesn't increase, if you run an ntsc c64 at double speed, it produces 120Hz and frames will be dropped (assuming the screenupdate is locked to the vsync of your videocard) unless your videocard runs at 120Hz. If the emulator does not lock to the vsync of your video card, and writes 120fps you would see tearing. LOL The C64 emulator produces 3 frames per second in RoF. Using double speed would result in 6 FpS... 120Hz means 20 times faster screen refresh. The Atari emulator runs at 26x speed and the game is still fluent. The faster emulation shows exactly what I was mentioning before. The C64 version uses tricks to run the CPU as fast as possible. When you do faster speed with "50hz" games on the C64 emulator, the games still stands fluent... faster and fluent, because it uses hardware features. In RoF it produces garbage, because some essential timings get messed. The Atari version runs 100% at VBI, thus it is speed independend correctly working. Edited October 21, 2009 by emkay Link to comment Share on other sites More sharing options...
emkay Posted October 21, 2009 Share Posted October 21, 2009 When you turn Vice to double speed ALL is running at double speed. And when playing a game -- using sprites-- it is working at full frames, it is even doubled , and clean.... not jumpy, just fluent... No, what TMR means is, that if the C64 version was programmed with e.g. a more rough movement in bigger steps due to limited processing power, speeding up the emulation would not help to get a more fluent movement. It still is rough, but of course faster. And that is what not fit to the statement of different C64 guys. It's still said that C64 does the same calculations but slower, which is simply not true. Link to comment Share on other sites More sharing options...
emkay Posted October 21, 2009 Share Posted October 21, 2009 I'm still at the point that the A8 does more calculations , does them faster, AND, it could get faster with some CPU optimising, as done in the C64 version. Link to comment Share on other sites More sharing options...
PeteD Posted October 21, 2009 Share Posted October 21, 2009 I'm still at the point that the A8 does more calculations , does them faster, AND, it could get faster with some CPU optimising, as done in the C64 version. Nobody is arguing that a 1.8mhz cpu is going to do the maths faster than a 1mhz one. Anyone doing so would be stupid. If the A8 is doing MORE calcualtions? well I don't see why. It needs the heights for every different pixel column it draws. If the A8 and C64 are both in 160 wide mode then there's absolutely no difference in the maths. The A8 however only draws 1/2 the vertical res so gains some more speed that way. What people are saying and you're not understanding is all to do with the rendering/running/moving speed, your insistence that its somehow not drawing part of the screen and your misunderstanding that somehow running a 60hz emu at 120hz means its 20x faster?? Pete Link to comment Share on other sites More sharing options...
Crazyace Posted October 21, 2009 Share Posted October 21, 2009 Has anyone looked at the c64 code for ROF , I wonder if it was broken during the conversion - I'd only really expect half speed for the C64 compared to the Atari ( lower cpu speed + extra overhead for filling in 2x lines ) and it does seem a lot slower. Link to comment Share on other sites More sharing options...
PeteD Posted October 21, 2009 Share Posted October 21, 2009 (edited) Has anyone looked at the c64 code for ROF , I wonder if it was broken during the conversion - I'd only really expect half speed for the C64 compared to the Atari ( lower cpu speed + extra overhead for filling in 2x lines ) and it does seem a lot slower. Depending on how the rendering is done I can see it being anywhere from 1/2 to 1/4 the speed. If you take into account you've already got a nearly 2:1 cpu advantage and then another 2:1 advantage for drawing 1/2 the lines, that's 4:1. The A8 uses line mode so if it renders horizontally it can just do a byte at a time ,x/y where the C64 will always end up needing something more complex due to its screen layout (+8 to get to the next horizontal byte which ends up not fitting inside the nice 256 range) so that can have bad effects on the speed as well. That's of course speculation because I (like probably everyone here) haven't disassembled the code to see how it works. It's possible the renderer works a totally different way but you're still going to get a fair advantage only drawing 1/2 the lines so it's still going to be logically in the 1/2 to 1/4 speed range. Pete Edited October 21, 2009 by PeteD Link to comment Share on other sites More sharing options...
Lazarus Posted October 21, 2009 Share Posted October 21, 2009 Has anyone looked at the c64 code for ROF , I wonder if it was broken during the conversion - I'd only really expect half speed for the C64 compared to the Atari ( lower cpu speed + extra overhead for filling in 2x lines ) and it does seem a lot slower. 6 fps on A8, 3 fps on C64. I measured that with a stopwatch and a 20% speed emulation. Link to comment Share on other sites More sharing options...
oky2000 Posted October 21, 2009 Share Posted October 21, 2009 Masterblazer (or Ballblazer) doesn't use Loren's fractal graphics though Listen, I'm tired of repeating myself. Just go and see the Masterblazer's credits sequence and stop acting like you don't understand simple sentences. 1. Post proper explanations... 2. Post videos... before getting your knickers in a twist The original cryptic moby games link showing six still images, and lack of other screenshots on HOL or youtube videos for a shit game I didn't have any interest in spending time finding and emulating didn't help. Finally after I did all the work found the ADF, ran the stupid game (I had no interest in running) after working out which combination of CHIP/FAST ram and OCS/ECS the awkward SoaB of a game required not to crash I have seen it and it seems to be an interpretation of the code rather than Loren's original code but who knows (and no linking some unexplained cryptic image in response, I haven't got time for that kind of crap again unless we are talking AAA Amiga titles I actually want to run anyway...life is too short to mess about working out your cryptic 'facts' dude) Link to comment Share on other sites More sharing options...
TMR Posted October 21, 2009 Share Posted October 21, 2009 The framerate of your pc doesn't increase, if you run an ntsc c64 at double speed, it produces 120Hz and frames will be dropped (assuming the screenupdate is locked to the vsync of your videocard) unless your videocard runs at 120Hz. If the emulator does not lock to the vsync of your video card, and writes 120fps you would see tearing. LOL The C64 emulator produces 3 frames per second in RoF. Using double speed would result in 6 FpS... 120Hz means 20 times faster screen refresh. This is you misunderstanding. The C64 is constantly outputting at 60Hz (NTSC) but the game spends multiple frames doing the calculations and drawing the back buffer. When you have VICE cranked up to 200% speed, the virtual C64 is now producing 120 frames a second, so is indeed kicking out frames at what amounts to 120Hz but since the average PC doesn't run the display at that speed you're only seeing however many the refresh speed of your card and adapter can handle, trying to push more through would cause tearing. At 200% emulation speed, the game still turns the same number of degrees each update and those updates happen twice as often, but the game isn't aware of that because it can't see past the virtual C64 and that's telling it there's nothing out of the ordinary and a 1MHz CPU. The Atari emulator runs at 26x speed and the game is still fluent. Now where you're getting the 26x speed rubbish from i'm not sure. Both emulators run at the same speed, the output speed of the machine - that's 50FPS for PAL, 60FPS for NTSC. Don't mix the frame rates of the game up with that of the hardware. The Atari version runs 100% at VBI, thus it is speed independend correctly working. The C64 version is synchronised to the vertical blank as well, i've already explained the tests i did to confirm that and it was why i mentioned slowing VICE down in the first place; if you drop it back to 20% speed you can see the buffers flipping and they're clean, any "garbage" or tearing you're seeing is being introduced by the emulation and the PC driving it. It's possible to trash the colour RAM of one buffer to see it and the other swapping over. Link to comment Share on other sites More sharing options...
andym00 Posted October 21, 2009 Share Posted October 21, 2009 Has anyone looked at the c64 code for ROF , I wonder if it was broken during the conversion - I'd only really expect half speed for the C64 compared to the Atari ( lower cpu speed + extra overhead for filling in 2x lines ) and it does seem a lot slower. 6 fps on A8, 3 fps on C64. I measured that with a stopwatch and a 20% speed emulation. At last someone could be bothered to do that Link to comment Share on other sites More sharing options...
TMR Posted October 21, 2009 Share Posted October 21, 2009 That's of course speculation because I (like probably everyone here) haven't disassembled the code to see how it works. It's possible the renderer works a totally different way but you're still going to get a fair advantage only drawing 1/2 the lines so it's still going to be logically in the 1/2 to 1/4 speed range. There's always the possibility that, since they're both locked down to the vertical blank, the A8 version is only just getting into a third frame and the C64 is grinding up against the end of the sixth... Link to comment Share on other sites More sharing options...
andym00 Posted October 21, 2009 Share Posted October 21, 2009 That's of course speculation because I (like probably everyone here) haven't disassembled the code to see how it works. It's possible the renderer works a totally different way but you're still going to get a fair advantage only drawing 1/2 the lines so it's still going to be logically in the 1/2 to 1/4 speed range. There's always the possibility that, since they're both locked down to the vertical blank, the A8 version is only just getting into a third frame and the C64 is grinding up against the end of the sixth... I think it's time to break out the disassemblers My curiousity has been aroused by all this RoF talk, and I for one am now very curious why it's that slow, even more so when KR is so much faster which clearly implies there were some massive speed-ups to be had in the idea.. Link to comment Share on other sites More sharing options...
Rockford Posted October 21, 2009 Share Posted October 21, 2009 I know what you mean and I'm familar with this feeling too! My condolences. Hi there, Irgendwer. How is your work going ? Have you managed to make these Lemon score comparisons ? LOL Did you come to tell us about the progress of your work or you just dropped by to say something comical...as always. Link to comment Share on other sites More sharing options...
Rockford Posted October 21, 2009 Share Posted October 21, 2009 (edited) Today another classic. 50 - GORF C64 C64 C64 The C64 version has better sound, hi-res graphics, sprites, and more colours. The Atari version has ugly low-res graphics, one-coloured and small sprites. C64 wins again. ATARI ATARI ATARI Edited October 21, 2009 by Rockford 1 Link to comment Share on other sites More sharing options...
PeteD Posted October 21, 2009 Share Posted October 21, 2009 If you want to see that it's drawing the whole terrain every time, run it, run a monitor and go here. Address $3766 You'll find the following LDA $DD00 AND #$FC ORA #$02 STA $F9 LDA #$78 STA $FA Then.. Address $378f LDA $DD00 AND #$FC ORA #$01 STA $F9 LDA #$08 STA $FA If you switch the ORA round (01 for the first code, 02 for the 2nd) and switch the LDA before the STA $FA (1st will be LDA #$08 2nd will be LDA #$78) it will switch the front and back buffers and you can see it draws EVERYTHING on each loop. Pete Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 21, 2009 Share Posted October 21, 2009 I already had done some researches... let me see what atariage search found... - RoFL does have 96 byte scanlines... why? 64/128 is better? - http://www.atariage.com/forums/topic/28214-how-can-we-get-these/page__p__318027__hl__rescue%20on%20fractalus__fromsearch__1entry318027 he following is a transcript of a letter from Loren Carpenter dated April 18, 1989. It details the use of fractals for real-time graphics rendering. I thought it might prove interesting to those who are also working on their own implementations of these algorithms. I have Loren Carpenter's acknowledgement of this posting. Relative to the fractal game algorithms... Neither I nor anyone at Lucasfilm ever published anything, as far as I can remember. I did the one for Rescue and the folks at LFL adapted it for Eidolon and Koronis later. Ballblazer doesn't use any fractal code. The algorithm is the simplest possible midpoint subdivision, subject to the constraint that the landscape be consistent from frame to frame. The random displacement is derived from 2 bits (sign & overflow) of the 8-bit sum of the tags on the ends of an edge. if overflow then displacement = 0 /* bisect the line */ else if negative displacement = -edge_length/4 else displacement = edge_length/4 The landscape is a 16x16 mesh of edges, repeating forever over the plane. There is a lot more detail, especially about perspective, but I'm not sure LFL wants me talking about it yet. Loren Carpenter Post Scriptum: For an in-depth treatment of fractals for graphics rendering, see Communications of the Association for Computing Machinery, Volume 25, Number 6, pages 371-84. The "...constraint that the landscape be consistent from frame to frame..." may refer to the idea of pixel replication as seen in games like Afterburner and Outrun. Note that as an object gets larger, it also gets blockier. Fractal code can appear to create detail very efficiently, making the object appear more complex than is otherwise possible. This can also be seen in the player vehicles in Ballblazer. Regarding perspective, two main techniques have been used in the past that I have noted. One is to use different shades of grey for mountains of different distance, and gradually change colours as the player moves closer or farther away. The other is most noticeable in Rescue on Fractalus, where there is a mesh that converges in the distance on a vanishing point. --- and somewhere there are some indepths where I went into Eidolon code and RoFL... Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts