emkay Posted July 1, 2009 Share Posted July 1, 2009 1. ENFORCER 2 - LEVEL 2 game play for sheer graphical power. Something the atari cannot do. But C64 also will never come close to this: 2. WIZBALL (the game) SID tune playing a FAULTLESS ELECTRIC GUITAR SOUND WITHOUT SAMPLES JUST STANDARD SID WAVEFORMS/FEATURES. Well, not digitising, but 200Hz programming is used there. But, where shall we find this "FAULTLESS ELECTRIC GUITAR SOUND WITHOUT SAMPLES JUST STANDARD SID WAVEFORMS/FEATURES" ? Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 1, 2009 Share Posted July 1, 2009 Every time I see Space Harrier I remember why I love my A8 Absolutely genius! sTeVE Link to comment Share on other sites More sharing options...
emkay Posted July 1, 2009 Share Posted July 1, 2009 (edited) Some desillusion about Enforcer 2 lvl 2 While the sprites look quite nice, the backround appears very bad by the easily recognizable character based parallax scrolling. Well, this type of parallax looked quite interesting in 160 resolution, but in 320 res. it looks like huge black glaciers. It actually looks worse when it comes to movement, than the attached part of the gamescreen already shows... Edited July 1, 2009 by emkay Link to comment Share on other sites More sharing options...
atariksi Posted July 1, 2009 Share Posted July 1, 2009 ...IMHO Atari has many good features, but what it lacks is uniformity of them... And those "Special cases" killed more than one project... ... It's pretty uniform except to get more colors than what the standard modes support. I call it compressed bit-depth. You find it more on Amiga and Atari 8-bits-- to squeeze more colors using less bandwidth than it would actually take. Amiga does the 12-bit (4096) color mode using 6 bitplanes along with Copper color changes and Atari does GPRIOR mode "0" and DLIs/sprite overlaps/etc. >Yes C64 has those limits as three colors in 4x8 block, but - blocks are same all over screen.... Is that an upper limit-- 3 colors in 4*8 block. I thought they can get more. It is 4 colors... One background color for whole screen area (unless you change it using rasters, something that creatures and mayhem games did...) + 3 colors for each character.... Two 4bit values in screen ram, and 4 bit value in color ram.... So you get up in the morning, make coffee, sit in front of computer, and 5 minutes later you can have nice colored game, with objects freely flying around the screen without any use of mind boggling tricks That is what I'm trying to say.... ... Well, that's subjective. You can also have nice graphics set up in BASIC on Atari with little effort and it uses linear graphics. Most of the examples I gave in this topic are in BASIC. You know commands like Sound, Graphics, Plot, Drawto, etc. >Yes it has "only" 8 sprites, but - they are all same size! Atari has 5 sprites if you want to think uniformly-- 8*248. It's just it's flexibility that they can be used in other ways. >>That is fine.... only problem is that 8<24, and 5<8 Yes, you do have more horizontal coverage as I already admitted but I was answering you about uniformity. >>Not to mention colors.... >>Colors are not uniform... First four yes, but that fifth one is a problem... I thought your C64 also used char-based color schemes so 5th one is also not a problem for you. Colors are 16/9/16 linear in GTIA modes. >Not in regular use, but in those tricky modes... >Its color is pulled from already used color register so you have large palette but can not choose freely any color... If you want to use BASIC and make things simple, yeah, you have 9 colors linear free to use from a palette in Graphics 10. Of course, you can write a DL in BASIC as well and have the advantages of various mixed modes. But making things simple as in BASIC won't really show strengths of either machine. >So what you gain in vertical, you lose much more in horizontal... Not really. If you calculate sprite coverage you will see that 5*248 is more sprite coverage than 24*21*8. Link to comment Share on other sites More sharing options...
atariksi Posted July 1, 2009 Share Posted July 1, 2009 But you're right.. The sprites are a pain when it comes to handling cycle exact stuff, especially a badline with all 8 sprites enabled.. But you work around that in whatever you're building.. And the benefits of them more than outweigh the downsides.. If you really must, you can always stretch (not multiplex!) the sprites down the screen completely to ensure consistent timing, and then through judicious use of sprite pointers change the sprite pointer to change data in a line by line basis, so even if the sprite wasn't displayed, you'd still be setting it to empty sprite data.. But this is exploiting more bugs in Vic so it probably doesn't count in your books since it's not a 'hardware' feature Bugs are used on both sides quite a lot nowadays, and if the A8 programmers used no tricks/hacks/bugs then their games would look like 4 colours total on screen 1982 crap that we had to endure on the C64 due to programmer ignorance That's a typical fanboy argument. "1982 crap". Your subjective biased opinion. I think many of the 1982 and before games are excellent. Games don't have to use all the capabilities of the hardware to be good. By the way, andym00 made a straw-man argument and you supported it which means another fanboyish mentality. I never said anything about not being able to use "bugs" in hardware. I was talking about consistency of making it run on all machines. Go read it yourself. Don't get your Atari knickers in a twist luv! '1982 crap' refers specifically to Commodore C64 games... ... I was referring to both machines unlike you who are clearly biased toward your C64. Your claiming someone to be a fanboy doesn't make him so. You have yet to given any proof. You are a "monkey" so does that make you a monkey. >Use more than 8 sprites on screen. I can use more than 8 sprites per screen. I can do 2000 sprites per screen as I already stated in this thread. You have more coverage horizontally on C64. No fanboyism-- just facts. >What ARE bugs are things like sprites in the borders, creating more than 16 colours, sample playback on the 6581 (not 8580) version of the SID etc etc. I never dismissed bugs; I said if they don't work consistently across machines-- you can't compare it with a standard feature on Atari (example was scrolling). >That is the whole point, 160 pages of waffle from a few Atari fan boys like you, and ZERO EVIDENCE of any actual physical improvement on these two graphical and aural masterpieces. All I see are theories and static pictures (some of which use PMs just to display more colours making it unlikely to use in games) or some weird lower resolution or flickery/horizontal banding type screen output. I also posted pictures that are undoable on C64. But I don't claim, unless C64 can do this image Atari is superior. There are many other things to consider. >If you have something to show me great, if not then your fanboy trollings/straw-man distracting type comments will be ignored. Where'the fanboy trolling??? You are making some blind asserations without any evidence. I provided sample code, but you are just proving yourself a fanboy without absurd conclusions based on limited experience of a few games. Link to comment Share on other sites More sharing options...
atariksi Posted July 1, 2009 Share Posted July 1, 2009 That's a typical fanboy argument. "1982 crap". Your subjective biased opinion. I think many of the 1982 and before games are excellent. Games don't have to use all the capabilities of the hardware to be good. By the way, andym00 made a straw-man argument and you supported it which means another fanboyish mentality. I never said anything about not being able to use "bugs" in hardware. I was talking about consistency of making it run on all machines. Go read it yourself. Please don't confuse me with a fanboy here Atariski, like both, I have owned both for a very long time.. I'm simply trying to get some balanced view of what both are capable of technically.. Apparently it's fine for the A8 team to throw around ideas that are nigh on impossible to implement if not impossible, only to be greeted by the cheer of the supporters.. You questioned some facts I stated, I answered all of them.. The only one throwing blatently inaccurate facts around is you, and people choose to ignore when you do so.. Ie: with regards to your statements on the multiple processors configurations of Pet computers.. Anyway regards your straw-man distraction I'm not playing your games, you've had your questions answered.. Regards your point about VSP ? I suggest you go read up.. The only issues are with demos (no surprise really there).. The games that use this don't have a problem.. You go figure why, it's not rocket science really.. I figure the only way to answer this is to build a technical prototype for a game on both and then see.. I guess 3D is out because we've a weaker processor as has been agreed on.. Both since it's clear from the rational discussion here that the A8 can match the 64 on all other aspects if not exceed it in many areas, pick your poison.. edit: I don't really expect any sensible outcome to come from this, but I'm open to this if it remains civil.. I never stated you were a fanboy-- I have yet to reply to your post about avoiding jitter as I have not gotten down to computing exactly the cycles involved and used. I was replying to someone else. Your claim that I don't consider features of hardware that are bugs is a straw-man argument. I'll prove it by quoting to you my original posting which you replied to. You can stop with the speculations "don't expect any sensible outcome" until you have evidence. Link to comment Share on other sites More sharing options...
atariksi Posted July 1, 2009 Share Posted July 1, 2009 You know I agree horizontally both Atari and Amiga have lesser sprite coverage, but some games are planned to use the advantage of the taller sprites (like River Raid). Similarly, you can target the machines strengths like hardware scrolling and mixing modes which would end up costing you a lot more cycles when porting to C64. Just like when you take horizontally wider sprites and try to port on Atari/Amiga, it costs the latter machines more cycles of CPU time by replicating horizontally or substituting with software versions. Amiga can also replicate sprites horizontally using it's similar GRAFn registers. But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ? Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do.. There's never any large copies, just updating new data at the edge of the screen as required.. I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges.. "Very flexible" so much so that it doesn't even work consistently on all machines. Unlike DLs which is a standard feature on all 8-bit computers since CTIA and scrolls per scanline and w/overscan or without. There's some stuff like shifting pixels in Graphics 9 that works on some machines, but at least say something that's consistent and doesn't garble the memory and risk computer software failure. And regardless, the point is things supported in hardware in a machine will always be better than doing them in software unless you have a lot of free CPU time compared to the other machine. Take collision detection as an example-- it definitely helps in games that need CPU power to do other things. That's the original posting. Nothing about me not accepting things that are hardware bugs. Link to comment Share on other sites More sharing options...
José Pereira Posted July 1, 2009 Share Posted July 1, 2009 Sorry to be here again. Am I right in what I said, or not, about C64 sprites? José Pereira. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 1, 2009 Share Posted July 1, 2009 Now I tell you one truth.. I do not care about who is better in what... why? simply because I have XX-KN-6502 on my car registration... so...I am fan of the RISC cpu and nowadays not more who can do what better... I would blame more Z80 speccy or armstrad... (ok... but not any z80 machine like msx, sega, gameboy...) interesting... when writing above... Z80 was used in many arcades and many asian machines while 6502 in many western arcades and machines... why did nintendo used the 6502 or 65816 instead of the more common z80??? Link to comment Share on other sites More sharing options...
Irgendwer Posted July 1, 2009 Share Posted July 1, 2009 .. Irgendwer offered to take a look at The Sentinel but hasn't had much opportunity to do so (something common to us all) ... ...which is also justified by the fact, that own developments normally make more fun and better 'paid' - thanks to the 'ABBUC contests'... CU Irgendwer Link to comment Share on other sites More sharing options...
popmilo Posted July 1, 2009 Share Posted July 1, 2009 >> And the real thing, I came here today it's to explain something about C64 sprites: >> - 8 Sprites - 1 colour eachone. - 8 adresses. >> - Multicolour - The other 2 colours, to join each sprite, only have two adresses. So You can create 8 different colour sprites but the other 2colours on multicoloured way in each sprite will be the same 2 >> colours in all the 8 sprites. And this 2 colours can only be from colours 1 to 8. C64 has 8 sprites. +Each can be Hires 24x21, or Multicolor 12x21 +Each has one color freely chosen from 16 colors. +If it is multicolor then it has two more colors freely chosen from 16. -Those two colors are same for all 8 sprites. +These colors are completely independent from background colors (included character or bitmap graphic). +Any sprite can be positioned anywhere on the screen +Each sprite occupies only 64 bytes of data - no need for copying data when changing shape of sprite. +To change shape of sprite, it is enough to change one byte - sprite pointer. +sprite pointers are always on end of screen ram - so changing address of screenram (one byte) changes whole 8 sprite pointers. +Sprites can be reused vertically - multiplexed - to cover whole hight of screen Compared to Atari it looks like this: -You have 4 players. -Each can be only 8 pixels wide. -And those pixels are 2 hires pixels wide. -They can not be 1 hires pixel wide. +players and missiles are 256 bytes high -Players can be moved only horizontaly -If you want to move them vertically you have to change their address pointer or copy player shape inside those 256 bytes +Each has one color freely chosen from whole palette of 128 colors. -Players themselves can not be multicolored. --Only combination of two players produce additional color and that color is dependent on the two colors of players - so it is not freely chosen from palete... +Player colors are also indepedent from background color. +You have 4 more missiles -They are 2 pixels wide -Their color is same as coresponding player +they can be combined into 5th player -Color of the fifth player is same as playfield 3 color - not freely chosen. +Players and missiles can be reused horizontaly but very time sensitive >>- Then they have a register to give the colour number of background. I think, this is the best think they have. Why? They can create a sprite and a great part of it could be like a real sprite. In A8, backgr. will always have less in priority. Dont understand that one.... >> 2nd. - 8 different colour sprites but all the other 2colours the same and only from 1 to 8 colour numbers - just see their Horizontal shoot'en'ups (Armalyte it is a good example). As I said NO. 2 colors same for 8 sprites but freely chosen from 16. Only in multicolored character mode are you restricted on first 8 colors as third color for each character but you have that upper bit that is used to chose if character is to be displayed hires or multicolor. >> 3rd. - The background colour registrer on their book, just see Golden Axe, and I think all the others horizontal beat'em'ups (and more type of games). You always see black (like ZX., black, almost always as background and/or border colour) around the main sprite colours. The only thing I don´t know and don't understand until today, it's that it was not just a border black line. Like just a single pixel design around the main character colours (In Last Ninja, my crazy game, it was possible they (John Twiddy and ...) do all the players as background, just a little part, like faces and hands as real sprites. I count all the sizes and in horizontal, if they put 8 hi-resol. sprites, I think it was impossible. Why? Because, if black was used as a sprite, with the weapon on horizontal way it was 4sprites x 8pixels for the enemy and the same fot the black body of enemy. They will not have any other sprites for hands, clothes and faces. Ok. I know they also have on that sprite table, an adress of interrupt, they call ir IRQ.) I always said to you, I never was, never, a programmer. This is why I want to ear from you!... Once again. am I right? (answers on a postcard... - just kidding). I think you got something wrong from that manual "4 sprites x 8 pixels for the enemy" ? You have data now, do the math.... +8 sprites give 8x24 hires pixels coverage =192 pixels... +or 8x12 multicolored=96 pixels... that is 60% of screen... -Ataris "multicolored" player combinations cover only 20 pixels wide area... -That is only 12.5% of screen... >>This don't show A8 it's better. No, probably not so bad in Sprites talk. But as I always said and think: IT CAN DO BETTER!... IF WE ONLY HAVE ... ... ... I think if you count all the + and - you'll find C64 sprites to be a "LITTLE" better than Ataris players and missiless Link to comment Share on other sites More sharing options...
popmilo Posted July 1, 2009 Share Posted July 1, 2009 .. Irgendwer offered to take a look at The Sentinel but hasn't had much opportunity to do so (something common to us all) ... ...which is also justified by the fact, that own developments normally make more fun and better 'paid' - thanks to the 'ABBUC contests'... CU Irgendwer Am I right to understand that someone took C64 game code and tried to analyze it so it could be ported to Atari ? Wouldn't it be easier to make new code ? Link to comment Share on other sites More sharing options...
popmilo Posted July 1, 2009 Share Posted July 1, 2009 Well, that's subjective. You can also have nice graphics set up in BASIC on Atari with little effort and it uses linear graphics. Most of the examples I gave in this topic are in BASIC. You know commands like Sound, Graphics, Plot, Drawto, etc. Yeah, but I can have 16 colored game with those 16 colors spread out on whole screen with little restrictions with no effort at all.. You can not put your 23 colors on whole screen in any resolution that is enough for a decent game ... I thought your C64 also used char-based color schemes so 5th one is also not a problem for you. Colors are 16/9/16 linear in GTIA modes. Yeah, but on C64 we can chose that third color to be any of first 8 in palette ... So we have 3+1from8 On Atari we have twice less characters (128) and that "5th" color is a product of 8 bit in char code... So you have 3+1from2 So if Ataris 5 means 3+1from2 Than C64 has 3+1from8=11 colors character mode! >Not in regular use, but in those tricky modes...>Its color is pulled from already used color register so you have large palette but can not choose freely any color... If you want to use BASIC and make things simple, yeah, you have 9 colors linear free to use from a palette in Graphics 10. Of course, you can write a DL in BASIC as well and have the advantages of various mixed modes. But making things simple as in BASIC won't really show strengths of either machine. I agree on GTIA modes - great example of uniformity, linearity and great choice of colors... Even I did DLI list in one afternoon... And made 80x50 screen in 9 colors Problem is - its maybe good for 3D games but for 2D ??? >So what you gain in vertical, you lose much more in horizontal...Not really. If you calculate sprite coverage you will see that 5*248 is more sprite coverage than 24*21*8. Atari 5x8x248=9920 pixels C64 8x24x21=4032 pixels If I reuse every sprite at least once... and then add 4 more... (and that can be done in 2 raster interupts...) I get 20x24x21=10080 pixels Now you can argue that you can do horizontal replication... but come on... You gotta admit its more practical to reuse C64 sprites verticaly than Players horizontaly... ? Eeeee.... If only, C64 would have Horizontal replication.... Link to comment Share on other sites More sharing options...
Irgendwer Posted July 1, 2009 Share Posted July 1, 2009 Wouldn't it be easier to make new code ? No, I don't think so. CU Irgendwer Link to comment Share on other sites More sharing options...
atariksi Posted July 2, 2009 Share Posted July 2, 2009 PMSL. It's funny how the C= guys hassle the Atari for the couple of things that have to be done in a complex way, but with the C-64, it comes down to fiddly time critical stuff just to perform simple functions like changing the screen base at byte granularity. What puzzles me is - what happens when you're doing this V-Scrolling with a wraparound screen that starts 200 bytes later than normal? Aren't you going to have the Sprite Data Pointers appearing onscreen... so you've got the problem where you can only have one thing or the other. I don't think we're hassling you over this, I'm just finding it mind meltingly complex to envision the idea of splitting sprites horizontally (edit: as Jetboot Jack seems to think also (sorry I got you two confused there for a minute)) in the context of a game and this 23 colour overlay mind-melt mode.. That's something I really wouldn't want to get into.. And if there was anyway we could re-use sprites horizontally of the 64 I'm sure it would have been used already, unfortunately we can't because once the sprite graphics shift registers have emptied there's no way to reload them until the next normal sprite DMA takes place, which is a bit of a bummer.. Timing on the 64 is more of a pain since we have no lovely WSYNC, but with the CIA timing method mentioned before, it's not really so much of a problem, or in fact with any of the multitude ways of obtaining stable timing.. I just happen to like the elegance of the CIA method personally As for the sprite pointers being shifted into the visible screen there's two ways to deal with it.. Some games just design the levels around that, and ensure they're not visible in the level (either via colour ram if in char mode or bitmap data if in bitmap mode), but another way is to have a another character screen that holds the correct sprite pointers, and then swap banks over the single line where the sprite fetches would be otherwise be wrong.. There's only exactly one line on screen where this needs to be done, so it's not exactly a show-stopper in anyway at all.. I don't think sprite replication on Atari or 23 color GPRIOR is as complex as doing time critical things on C64 given no hardware support for them and giving burden to software to deal with it. GPRIOR can be used even in BASIC as I gave the code already. Delaying DMA cycles to get some effects isn't your normal coding especially when you have to deal with the BA signals caused by color RAM and sprite motion. And now you combine stuff like line-based scrolling and overscan/underscan and your timing can't be used anymore. You are blaming me for claiming things impossible but I already gave code for them in BASIC yet you are trying to explain things that would require cycle-exact coding and more overhead in software than Atari doing it via it's DL and hardware registers. Link to comment Share on other sites More sharing options...
atariksi Posted July 2, 2009 Share Posted July 2, 2009 Well, that's subjective. You can also have nice graphics set up in BASIC on Atari with little effort and it uses linear graphics. Most of the examples I gave in this topic are in BASIC. You know commands like Sound, Graphics, Plot, Drawto, etc. Yeah, but I can have 16 colored game with those 16 colors spread out on whole screen with little restrictions with no effort at all.. You can not put your 23 colors on whole screen in any resolution that is enough for a decent game ... ... We were arguing over simplicity and Atari has quite a few things that can be done simply using even BASIC. Yeah, to go beyond it's standard modes, you need to use DLIs and IRQs or whatever. But it's quite easy to have a GITA 16-color mode with GPRIOR enabled and sprites overlayed even in BASIC. Getting more than 5 sprites per line would require some complexity. I thought your C64 also used char-based color schemes so 5th one is also not a problem for you. Colors are 16/9/16 linear in GTIA modes. >Yeah, but on C64 we can chose that third color to be any of first 8 in palette ... >So we have 3+1from8 >On Atari we have twice less characters (128) and that "5th" color is a product of 8 bit in char code... >So you have 3+1from2 >So if Ataris 5 means 3+1from2 >Than C64 has 3+1from8=11 colors character mode! Again, you claimed 5-color mode was complex and I stated it's like C64 char mode. For simplicity, the linear modes are there but then where's the linear mode on C64? >I agree on GTIA modes - great example of uniformity, linearity and great choice of colors... >Even I did DLI list in one afternoon... >And made 80x50 screen in 9 colors >Problem is - its maybe good for 3D games but for 2D ??? Sprites are same resolution even in GTIA modes so only your background graphics would be half horizontal resolution at 80*200 (again without resorting to DLI coding). >Atari 5x8x248=9920 pixels >C64 8x24x21=4032 pixels >If I reuse every sprite at least once... and then add 4 more... >(and that can be done in 2 raster interupts...) >I get 20x24x21=10080 pixels >Now you can argue that you can do horizontal replication... but come on... You gotta admit its more practical to reuse C64 sprites verticaly than Players horizontaly... ? No, I won't argue that because your point was about simplicity so multiplexing is no longer as simple as just putting up sprites on screen. >Eeeee.... If only, C64 would have Horizontal replication.... There's two ways to expand sprite coverage-- horizontal replication is one but there's also the zoom option with GPRIOR enabled. Hi-res sprite effects also done in hi-res modes with GPRIOR settings. Link to comment Share on other sites More sharing options...
atarian63 Posted July 2, 2009 Share Posted July 2, 2009 I'd like to see those Commodore games that allegedly trump the Atari. What are the titles? I have only recently begun playing C64 and for the most part, things look pretty similar to me (this is a compliment). I hope there are NTSC versions, because I'd like to play them on my real Commodore. Maniac Mansion Zak McKracken and the Alien Mindbenders Turrican Turrican II: The Final Fight Creatures Creatures 2: Torture Trouble Great Giana Sisters, The Armalyte Mayhem in Monsterland Laser Squad Bubble Bobble Katakis Newcomer Rainbow Islands Wizball Rick Dangerous Rick Dangerous II Enforcer: Fullmetal Megablaster MYTH: History in the Making Midnight Resistance Rodland Look them up on http://noname.c64.org/csdb/ ... How can they trump the Atari when they were not made in an Atari version? Link to comment Share on other sites More sharing options...
atariksi Posted July 2, 2009 Share Posted July 2, 2009 ...So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well.. I'm all for commodore but have to correct you In every line where you use sprites VIC has to read pointer and sprite data... So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins... So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles... It's not without cost And as I know one line is 63 cycles long on PAL system ? 25 badlines = 25 * 21 (23 cpu cycles remaining per BL).. 175 normal lines = 175 * 63 112 blanked lines = 112 * 63 So we get 18606 cycles per frame.. But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution... As Rybags stated in post #6443, it's not just cycles you have to look at but uniformity of it and being able to sync up to particular cycles and I would say exactness of them. I can play back a digitized audio file knowing DMA is pretty much uniform in graphics modes (no bad lines). So what happens when you play audio with bad lines on C64? What's the worst case latency? And then of course those sprites and color RAM don't always use up same number of cycles so writing kernels would be a much more difficult task. Atari CPU clock syncs up with video color burst. PAL/NTSC have same number of CPU cycles/scanline on Atari so one version of kernel will work on both machines. And you can use sprites in replicate mode w/screen off and get 105 cycles/scanline (27510/frame NTSC or 32760/frame PAL) for applications that need the time. Easily handled, but since we've less CPU power, this is more of a pain.. The easy way to handle the jitter is to point the NMIs directly at the CIA registers.. Set a counter that counts down from the desired cycle count, and when it triggers, (we've programmed the previous timer register to hold a jmp abs opcode) the NMI will jump to the correct routine based upon the cycle count.. You simply have 8 routines that are coded to each be 0 to 7 cycles of jitter.. This also means that we don't have to waste those cycles.. I mean that if the jitter is at least 4 cycles or more then we can ack the nmi.. So useful work is done instead of just burning cycles.. Clearly what work is app specific... So you're pointing the NMI vector directly at the hardware registers ) It's very evil, but a lovely solution.. ... Lovely is when it's simple and exact and relies less on software and more on hardware. It's good that you have some workarounds but not as good as hardware support for it. >By correct initial triggering of the timer, you have more than enough time to execute your sample playback even on a badline (which has 23 cycles left) as long as you align the initial interrupt point nicely.. Yeah, we burn some cycles, but it's a simple and easy way to handle the jitter.. >But as for playing audio on badlines.. You just simply wouldn't.. I wouldn't dream of trying 15.6Khz playback on the c64 in a games (without a cycle fixed kernel).. 7.8Khz no problem, you just make sure you don't interrupt on badlines when you fire up the interrupt You do need to play audio on badlines-- most of audio files/audio recorders nowadays are on Windows which uses 11Khz, 22Khz, etc. so if you use 11Khz, you end up with playing audio on badlines. >But you're right.. The sprites are a pain when it comes to handling cycle exact stuff, especially a badline with all 8 sprites enabled.. But you work around that in whatever you're building.. And the benefits of them more than outweigh the downsides.. If you really must, you can always stretch (not multiplex!) the sprites down the screen completely to ensure consistent timing, and then through judicious use of sprite pointers change the sprite pointer to change data in a line by line basis, so even if the sprite wasn't displayed, you'd still be setting it to empty sprite data.. But this is exploiting more bugs in Vic so it probably doesn't count in your books since it's not a 'hardware' feature Stretching sprites by constantly modifying some register every scanline is still not as good as GTIA automatically replicating the sprites for you. You have more software burden involved. In my book if hardware can consistently do it, it's a feature even if happens to be not the intention of the designer. >Or another way, in your multiplexor, just ensure that unused sprites are re-enabled immediately with an empty pattern, a little more work for the plexor (and adds a few minor potential restrictions), but then you have absolutely uniform cycle availability over the displayed frame.. >But we're way outside of typical game scenarios here and firmly into demo land now with sprite stretching.. >But in answer to your question the handling of interrupt jitter is a no brainer really.. It's a "no brainer" at the cost of complexity; it more complex than the DLIs I posted earlier in this thread which execute cycle-exact code without relying on WSYNC. It requires that code be all exact in the background. Link to comment Share on other sites More sharing options...
atariksi Posted July 2, 2009 Share Posted July 2, 2009 That's a typical fanboy argument. "1982 crap". Your subjective biased opinion. I think many of the 1982 and before games are excellent. Games don't have to use all the capabilities of the hardware to be good. By the way, andym00 made a straw-man argument and you supported it which means another fanboyish mentality. I never said anything about not being able to use "bugs" in hardware. I was talking about consistency of making it run on all machines. Go read it yourself. ...be greeted by the cheer of the supporters.. You questioned some facts I stated, I answered all of them.. The only one throwing blatently inaccurate facts around is you, and people choose to ignore when you do so.. Ie: with regards to your statements on the multiple processors configurations of Pet computers.. ... Another speculative remark on your part: "only one throwing inaccurate facts around is you". I suppose you read all the bullcrap that so many C64 fans wrote in this forum and drew this conclusion? I don't know why you can't accept facts as they are stated and want to resort to attack people based on something unrelated to C64 vs. Atari. But let's get the posting # for the Pet stuff so I can see what you are referring to. >Anyway regards your straw-man distraction I'm not playing your games, you've had your questions answered.. Regards your point about VSP ? I suggest you go read up.. The only issues are with demos (no surprise really there).. The games that use this don't have a problem.. You go figure why, it's not rocket science really.. ... I have heard from many people about memory corruption using these DMA delay tricks. Link to comment Share on other sites More sharing options...
atariksi Posted July 2, 2009 Share Posted July 2, 2009 1. ENFORCER 2 - LEVEL 2 game play for sheer graphical power. Something the atari cannot do. But C64 also will never come close to this: 2. WIZBALL (the game) SID tune playing a FAULTLESS ELECTRIC GUITAR SOUND WITHOUT SAMPLES JUST STANDARD SID WAVEFORMS/FEATURES. Well, not digitising, but 200Hz programming is used there. But, where shall we find this "FAULTLESS ELECTRIC GUITAR SOUND WITHOUT SAMPLES JUST STANDARD SID WAVEFORMS/FEATURES" ? To conserve memory space, didn't early games all try to use sound effects on Atari games without samples? I think Joust bird sounds and sounds of stopping (putting on brakes), etc. are all non-sampled sounds. Just need a good model of the waveforms involved for the sound to be played. Link to comment Share on other sites More sharing options...
andym00 Posted July 2, 2009 Share Posted July 2, 2009 I don't think sprite replication on Atari or 23 color GPRIOR is as complex as doing time critical things on C64 given no hardware support for them and giving burden to software to deal with it. GPRIOR can be used even in BASIC as I gave the code already. Delaying DMA cycles to get some effects isn't your normal coding especially when you have to deal with the BA signals caused by color RAM and sprite motion. And now you combine stuff like line-based scrolling and overscan/underscan and your timing can't be used anymore. You are blaming me for claiming things impossible but I already gave code for them in BASIC yet you are trying to explain things that would require cycle-exact coding and more overhead in software than Atari doing it via it's DL and hardware registers. I beg to differ because the code involved is fairly constant, and very easy to set up.. Far far easier then this pie in the sky idea of horizontally multiplexing players.. I'm ready to be proved wrong on this, and would love to be.. Colour Ram doesn't incur any overhead on the 64.. Colour Ram is connected via a seperate bus to VIC internal 1k x 4bit memory.. Scrolling doesn't affect timing at all.. Timing is exactly the same.. You're BASIC example is exactly that.. It shows 23 colours, now do something sensible with if you please... Link to comment Share on other sites More sharing options...
andym00 Posted July 2, 2009 Share Posted July 2, 2009 Lovely is when it's simple and exact and relies less on software and more on hardware. It's good that you have some workarounds but not as good as hardware support for it. And the point of this is ? I'm not biased here at all.. If I knew the A8 as well as I know the 64, or the 7800 or the 2600 then I would be posting pro's and cons on both sides.. Since I don't, we're left in an ever decreasing circle of petulance from you.. You do need to play audio on badlines-- most of audio files/audio recorders nowadays are on Windows which uses 11Khz, 22Khz, etc. so if you use 11Khz, you end up with playing audio on badlines. Umm, we don't in the context of what we're talking about.. So, why would you use 11Khz or 22Khz ? Instead of 7.8Khz or 15.6 Khz then ? Go on, I'm dying to hear this answer.. I believe you're just being deliberately obtuse here now.. Next you'll be saying that the 64 fails because we can't have a 320x256 or 256x256 screen, because that's a common size of images on Windows.. I did hold you in some high regard up until now, but you've really just blown it with that Stretching sprites by constantly modifying some register every scanline is still not as good as GTIA automatically replicating the sprites for you. You have more software burden involved. In my book if hardware can consistently do it, it's a feature even if happens to be not the intention of the designer. I didn't say it was in this context.. I simply gave one of many ways of ensuring a constant set of cycles over the screen.. Your choice of word here, replicating, is deliberately chosen to mislead.. GTIA doesn't replicate sprites for you at all.. It has no idea of a sprite in the context of an isolated on screen object occupying a fixed vertical region, just an array of memory that it blindly displays down the height of the screen.. You're required to put the data in the right place, and handle the interrupts for positioning and colours, and that overhead of putting the data in the right place is not going to be insubstantial in a busy game.. Granted I'll give you the idea of a sprite being the full-screen height, but in the context you've chosen to write that and chosing to use the word replicating here you're trying to misconstrue again.. You're implying more than the hardware is capable of.. Anyway, by your own definition, the Vic supports variable hardware sprite stretching I don't believe this, but this is what your rules now say is possible.. Life in the world of Atarski could be fun So does this mean, that by messing with the sprite addressing hardware, and forcing it not to add 3 to each sprite line, and 2 instead (or the other possibilities, there are many!) that we support hardware sprite distortion ? Or maybe at a pinch, (holy crows!!!) hardware texture mapping!!! After all, we're just setting a register at the right time, and the hardware does the rest for the duration of the sprite.. And please, for the love of god, don't answer this It's a "no brainer" at the cost of complexity; it more complex than the DLIs I posted earlier in this thread which execute cycle-exact code without relying on WSYNC. It requires that code be all exact in the background. It's not.. I've told you once already how to ensure jitter free interrupts, you've chosen to ignore that.. Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2009 Share Posted July 2, 2009 Colour Ram doesn't incur any overhead on the 64.. Colour Ram is connected via a seperate bus to VIC internal 1k x 4bit memory.. And the reading of Colour RAM causes Cycle Stealing, as the Sprite reading does with the already slower CPU. Scrolling doesn't affect timing at all.. Timing is exactly the same.. Scrolling on the A8 is a bit odd. First it takes more DMA cycles , but when scrolling is working, the CPU gets cycles back. Link to comment Share on other sites More sharing options...
andym00 Posted July 2, 2009 Share Posted July 2, 2009 (edited) Another speculative remark on your part: "only one throwing inaccurate facts around is you". I suppose you read all the bullcrap that so many C64 fans wrote in this forum and drew this conclusion? I don't know why you can't accept facts as they are stated and want to resort to attack people based on something unrelated to C64 vs. Atari. But let's get the posting # for the Pet stuff so I can see what you are referring to. I have heard from many people about memory corruption using these DMA delay tricks. Okay okay, the choice of saying 'the only one' maybe wasn't the best first choice.. I've read most of this thread over it's life, and I've ignored most of the clearly wrong stuff because it wasn't being picked up on, or simply wasn't relevant, or simply didn't want to get involved.. I just feel that you're being overly vocal here and were thoroughly mispresenting the 64, and think it fair that it be pointed out that you've made mistakes in your statements before.. Though on the whole, bar being a bit wonky, you've done a fair job when not splitting hairs.. I'm not digging for that post, you can find it if you want.. It's where you're going on about pets and their cpu configurations.. I've also heard from many people about the memory corruption (I've also heard the moon is made of cheese), but that fact of the matter is there's a work around.. Demos don't care that the memory might corrupt, as long as it survives the duration of the effect.. Games obviously have different criteria.. No go figure why commerical games featuring these effects work fine.. Big cluestick time.. It's nothing to do with the memory refresh being altered by the dma-delay.. Edited July 2, 2009 by andym00 Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2009 Share Posted July 2, 2009 Some desillusion about Enforcer 2 lvl 2 While the sprites look quite nice, the backround appears very bad by the easily recognizable character based parallax scrolling. Well, this type of parallax looked quite interesting in 160 resolution, but in 320 res. it looks like huge black glaciers. It actually looks worse when it comes to movement, than the attached part of the gamescreen already shows... Hehe... Particular the 2nd level comes a bit toward the A8's features. I'm still thinking here of a gr. 0 game screen, the moving objects at 2x2 chars move 1x1 at char resolution. The "Walls" easily could be done with players. OK, the corrections would cost fullscreen CPU usage, but the objects would move fast enough. Parallax with "all" speeds would be possible then. And a simple adjustment on the players would result in a "ship behind the wall, or moving through a large plasma wall. Using black in the background would make it posible to give the moving objects metallic shining if using a player overlay or some other visual tricks. 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