atariksi Posted June 5, 2009 Share Posted June 5, 2009 I must just be me but I don't see how the GR8 with mismatched PMG overlays looks anywhere near as good as the C64 version... Given the picture is only a subset of the screen, wouldn't narrow mode w/some vertical overscan free up some cycles. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 5, 2009 Share Posted June 5, 2009 And that is exactly the way we approached it back when we were looking at developing the franchise on the A8 - narrow screen, all info above and below the play area... emkay - I knwo this is slightly OT, but popmilo's questions about sprites and his game is reflected in this approach, one that would not IMHO create a worthy game for the A8... sTeVE Link to comment Share on other sites More sharing options...
popmilo Posted June 5, 2009 Share Posted June 5, 2009 ps. btw... which c64 game are we talking about? if we can have a look then it might be easier to suggest the way to go? Turrican would be first rolemodel but not to exclude all other jumping, running and shooting games... Turrican was and is one of my favourite games of all times... I have c64, spectrum48,cpc464,amiga computers and atari800xl in my collection ... And it hurts me that the only computer that doesn't have a turrican port on it is Atari 800xl... It doesn't have to be clone of turrican... even static screens would be nice.... Just as long as you can jump and shoot a bunch of angry aliens from all kinds of weapons and explore big map... I know c64 had more games like that compared to atari800 so why not try to make the best that I can and make at least a demo level just to prove that machine can do it... Link to comment Share on other sites More sharing options...
popmilo Posted June 5, 2009 Share Posted June 5, 2009 "trying to make" ... the hits the spot. The C64's Sprites make some things easier. But, at the end, you don't have more than 16 colours on the screen. I don't need more than 16 colours For Atari I would stick to 5 color char mode software sprites + pmg for player... At the end what counts is playability .... (otherwise nobody would ever buy gameboy ) Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 5, 2009 Share Posted June 5, 2009 Link to comment Share on other sites More sharing options...
emkay Posted June 6, 2009 Share Posted June 6, 2009 (edited) You know that I am more into the atari, but this is nothing to me. IT is still the wrong start: Using all players for the Protagonist, and then it ends up with a not working sprite routine. We know that the Atari is optimised for LMS scrolling and DLI handling via DL commands. Dropzone beated the C64 in the count of calculated enemies by building up on those features. Actually. On the C64 (and following on the Amiga) , the scrolling stops when many moving objects were waiting to be triggered. Do I need to write more? The biggest "Trick" is to find a way for creating a graphics kernal at the height of the Protagonist's movement range. If the main "sprites" works fully fluent, I wouldn't care about the movement of the enemies. Every C64 user (and many Speccy users) will state a game using it, is a good one , even if the enemies move in charmode resolution. For the handling of the "charmode clusters" and the direction of shape movement. Well... If many objects move in the same direction, you simply could reuse the same chars (it will save cpu time and RAM consumption). And If objects move in different directions, make it interleaved.... (it will save cpu time and RAM consumption aswell) It works on all "3D" games on the C64 and it makes a huge amount of rotating objects on the C64 look faster than it is. Edited June 6, 2009 by emkay Link to comment Share on other sites More sharing options...
popmilo Posted June 6, 2009 Share Posted June 6, 2009 That turrican engine test video is too ... not good... I like this one more: I found this game... Cavelord It has 8 directions fast scroll, character based sprites , main character and two enemies I think made from Players... And background is clear... you know what is green, what is brown... Colors in that turrican mockup are to much blended with eachother... there is no difference between grass and stone... Better to use only one color for each... I agree with you Emkay... char based movement would work good enough for enemies... Test is needed... Could you please explain what did you mean with: >> The biggest "Trick" is to find a way for creating a graphics kernal at the height of the Protagonist's movement range. ? Link to comment Share on other sites More sharing options...
emkay Posted June 6, 2009 Share Posted June 6, 2009 Could you please explain what did you mean with:>> The biggest "Trick" is to find a way for creating a graphics kernal at the height of the Protagonist's movement range. ? Well. In a full software controlled gfx routine "kernal", you can multiplex everything. One possibility: The Turrican could be done with 4 Background colours of different grey shapes. But You'd need also the red dots ... you can do them with a player, but then you'd lose a Player for the rest of the screen. With multiplexing you could re use the player for the background (for example), or change some needed colour per scanline. Everything else (upper and lower range of the screen) could be done by using simple DLIs. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 6, 2009 Share Posted June 6, 2009 Please draw it... It makes no sense to me as you describe it, in fact it does not sound possible to re-create Turrican as you describe... sTeVE Link to comment Share on other sites More sharing options...
atariksi Posted June 6, 2009 Share Posted June 6, 2009 Please draw it... It makes no sense to me as you describe it, in fact it does not sound possible to re-create Turrican as you describe... sTeVE Is there a picture of what he's trying to draw and how many other players are moving? Link to comment Share on other sites More sharing options...
popmilo Posted June 6, 2009 Share Posted June 6, 2009 Well. In a full software controlled gfx routine "kernal", you can multiplex everything. I understand I can have more horizontal regions with more colors but that doesn't help much... Players are already high as screen so thats fine without multiplexing (if you don't count changing horisontal position as multiplexing...) The Turrican could be done with 4 Background colours of different grey shapes. But You'd need also the red dots ... you can do them with a player, but then you'd lose a Player for the rest of the screen. What he means with "Turrican" is the player sprite in turrican... I think I read somewhere that it is three sprites... Two normal multicolor sprites and one Y expanded under it or something like that... Point is it has 4 colors... Dark grey, Light grey, White and Red But I still dont understand what you mean with "4 background colours of different grey shapes" ? By the way... I wouldn't try to recreate graphics 100%... It just needs to "look alike" and behave in simmilar manner... With multiplexing you could re use the player for the background (for example), or change some needed colour per scanline. Everything else (upper and lower range of the screen) could be done by using simple DLIs. "Upper and lower range of screen" ? What do you mean with that? area above and under player or info panel wich is only at the bottom of screen ? Link to comment Share on other sites More sharing options...
emkay Posted June 7, 2009 Share Posted June 7, 2009 Well. In a full software controlled gfx routine "kernal", you can multiplex everything. I understand I can have more horizontal regions with more colors but that doesn't help much... Players are already high as screen so thats fine without multiplexing (if you don't count changing horisontal position as multiplexing...) Reusing the player in a scanline can help to enhance the colour resolution "dramatically" The Turrican could be done with 4 Background colours of different grey shapes. But You'd need also the red dots ... you can do them with a player, but then you'd lose a Player for the rest of the screen. What he means with "Turrican" is the player sprite in turrican... I think I read somewhere that it is three sprites... Two normal multicolor sprites and one Y expanded under it or something like that... Point is it has 4 colors... Dark grey, Light grey, White and Red But I still dont understand what you mean with "4 background colours of different grey shapes" ? It's a typo . and was intended "shades" not "shapes". By the way... I wouldn't try to recreate graphics 100%... It just needs to "look alike" and behave in simmilar manner... Indeed. The game may lose a colour -here and there- but the whole screen will remind of the Amiga version. With multiplexing you could re use the player for the background (for example), or change some needed colour per scanline. Everything else (upper and lower range of the screen) could be done by using simple DLIs. "Upper and lower range of screen" ? What do you mean with that? area above and under player or info panel wich is only at the bottom of screen ? With a "kernal" you can produce a "bubble" of extra colours around the protagonist. In the screen ranges above and below the protagonist, you don't need such "kernal". And it's not as hard as it might look for C64 guys. Because, the DLI is controlled via DL commands, you'd need just some "pokes" to keep the correct Y-position of that "kernal". Even vertical scrolling is not a handycap here. Link to comment Share on other sites More sharing options...
emkay Posted June 7, 2009 Share Posted June 7, 2009 Please draw it... Before you can draw a picture, you need a pencil and a paper. No Artist can draw a picture with his bare fingers onto a granite wall. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 7, 2009 Share Posted June 7, 2009 mock it up in photoshop then... sTeVE Link to comment Share on other sites More sharing options...
emkay Posted June 7, 2009 Share Posted June 7, 2009 (edited) mock it up in photoshop then... sTeVE Mockups never really work, but if you want one... 192x240 approx 32 colours and the single ranges use approx. 4 colours. Edited June 7, 2009 by emkay Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 7, 2009 Share Posted June 7, 2009 I don't see how that image is in anyway reproducible on the A8... It is also not a very representative image of Turrican these are far trickier - Link to comment Share on other sites More sharing options...
emkay Posted June 7, 2009 Share Posted June 7, 2009 I don't see how that image is in anyway reproducible on the A8... It is also not a very representative image of Turrican these are far trickier - The really tricky stuff is in the imagination of the viewer. OK, no hires would be possible there, but the parallax is really nothing special. Just 4 chars were used, rotating their content depending on the half of the scrolling speed. The 2nd trick is to use the moving objects at different framerates. There is no need to handle a sprite every frame that moves every 4th frame... Scrolling clearly can be 50Hz on a PAL system. The Turrican can move at 50Hz then aswell. Other objects fps may vary from 50fps to 3fps if necessary. Link to comment Share on other sites More sharing options...
popmilo Posted June 7, 2009 Share Posted June 7, 2009 The really tricky stuff is in the imagination of the viewer. OK, no hires would be possible there, but the parallax is really nothing special. Just 4 chars were used, rotating their content depending on the half of the scrolling speed.The 2nd trick is to use the moving objects at different framerates. There is no need to handle a sprite every frame that moves every 4th frame... Scrolling clearly can be 50Hz on a PAL system. The Turrican can move at 50Hz then aswell. Other objects fps may vary from 50fps to 3fps if necessary. I agree on animation speed... but parallax scrolling would demand software sprites with masking... or charbased masks... wich would look ugly... I wouldn't try to implement parallax scrolling as long as software sprites were involved... Better to stick with clean and colorfull background (dli coloured... ) than to mess it up.... So.... You are saying "Kernal" should be written for the area of screen that is covered with player ? Part of the screen between these two horizontal lines ? And in that kernal routine we should change color registers directly ? at the right time ? In one scanline ? I checked dma steal timing diagrams and it doesn't seam possible.... First line of each char row has absolutely no free cycles in the middle of row ..... Rest of the lines have roughly every other cycle free on the right side of screen and on the left side its like 3 nono cycles and then 1 free.... Where would you fit three color changes in that available time ? And to be precise enough ? And not to mention to put background colors back after main player zone ..... Link to comment Share on other sites More sharing options...
emkay Posted June 7, 2009 Share Posted June 7, 2009 The I checked dma steal timing diagrams and it doesn't seam possible.... First line of each char row has absolutely no free cycles in the middle of row ..... Rest of the lines have roughly every other cycle free on the right side of screen and on the left side its like 3 nono cycles and then 1 free.... Where would you fit three color changes in that available time ? And to be precise enough ? And not to mention to put background colors back after main player zone ..... Ofcourse every first line of a charmode line GTIA registers cannot be changed midline. That's why the first line has to fit to the protagonist's colour and PM usage. 2 player can be used to give two new colours to the background (resulting in 4 additional colours). You can double both of them and gain huge areas with extra colours. Those 2 players can have diferent colours aswell. To avoid the problem with the "bad" line, you can create patterns that don't use the colours in the first line. The "charset" sprites could do a half "charmode resolution" movement, to avoid the colour "jumping" there. and so on Link to comment Share on other sites More sharing options...
emkay Posted June 7, 2009 Share Posted June 7, 2009 but parallax scrolling would demand software sprites with masking... or charbased masks... wich would look ugly...I wouldn't try to implement parallax scrolling as long as software sprites were involved... Better to stick with clean and colorfull background (dli coloured... ) than to mess it up.... No, it doesn't look ugly if the game is running. Even on the C64 you have this and no one is blaming it. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 7, 2009 Share Posted June 7, 2009 I full understand not updating every entity, every tick emkay - I have some software development experience Although a 3hz update would look pretty chunky next to a 50hz one - probably best for VERY minor object motion... That does nothing to explain the image though - break it down more, explain the objects more clearly and color register use - just annotate the image, your textual explanation does not inform me well enough... sTeVE Link to comment Share on other sites More sharing options...
atariksi Posted June 9, 2009 Share Posted June 9, 2009 I full understand not updating every entity, every tick emkay - I have some software development experience Although a 3hz update would look pretty chunky next to a 50hz one - probably best for VERY minor object motion... That does nothing to explain the image though - break it down more, explain the objects more clearly and color register use - just annotate the image, your textual explanation does not inform me well enough... sTeVE I liked what you wrote previously where each machine should target it's games for its own hardware rather than try to port them over. So, given 8 colors produce 22 colors/scanline in 160*200 and one BAK so total is 23 colors/scanline. Now if we take 8*6 (48) cycles to re-use the colors and thus produce another 22 colors on the same scanline. This gives you 45 colors/scanline. So isn't this greater than color RAM total of 40 selectable colors/scanline? Obviously, they would be more clustered and not uniformly spread out, but images contain clusters of colors... Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 9, 2009 Share Posted June 9, 2009 I'd love to see that - a game at say 30hz with that many colors per scanline, that is more than pong, albeit colorful pong... Again I would settle for an ambition screen-shot, carefully annotated so I could understand the "goal" quality and the way it could be done. I can see 23 colors per line being possible, not very useful, but possible, ideally I would like a "do-able" image of a game - something I could see how to code up... Ideally though something coded game like, to prove the theory from yourself would be great... sTeVE Link to comment Share on other sites More sharing options...
youki Posted June 9, 2009 Share Posted June 9, 2009 Few demo of what a "C64" can do ... http://www.youtube.com/watch?v=tqHiYrAm2Qc...feature=related http://www.youtube.com/watch?v=xFilVEkTCjg...feature=related Link to comment Share on other sites More sharing options...
atariksi Posted June 9, 2009 Share Posted June 9, 2009 Few demo of what a "C64" can do ... ... Did they use LDA/STAs to move that picture or some hardware trick? That would answer which machine can do it better. 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