Wolfram Posted April 22, 2009 Share Posted April 22, 2009 8 pixel boundaries are irrelevant. Atari can have 3 bitmap lines, a character line, 2 bitmap lines, a character line. 0 CPU cost. And if you want to split hairs, with some CPU expenditure you can do shortened text modes, or vertically expansion on bitmap pixels. I think you can do 2X and 4X zoom horizontally on 160*200 without CPU expenditure by just changing DLs. Of course vertically you can zoom any amount 1X, 2X, 3X, 4X, 5X, etc. I suppose you can use nearest neigbor approach vertically and get fractional zoom factors. And then there's the mirror effect or repeating scanlines from the display, which is easily done with ANTIC (compressed display). And the ability to cause DLI on various length mode lines and also have the ability to do scanline based IRQs such that you can play back DAC audio during HBlanks. Atari is overall superior; only reason some people think C64 is superior is because they don't understand the Atari hardware. yeah, that's why it cant do the typical 80's game in c64 quality. Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 >c) My "And the c64 can do pixel perfect collision" was the beginning of a new point, which for some mysterious reason you trimmed. In fact, I said: You also have quoted others many times and NOT quote their entire message. There is more than one point-- so there's only need to quote the proof you asked so don't pretend there's some "mysterious" thing going on. Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 Apology to Wolfram: The only reason a die-hard Commodore user to come into an Atari forum is to stir up emotions in a flamewar. You succeeded! Nevertheless, I apologize for name-calling, etc. You still have every right to be here, and you shouldn't be called anything. My apologies for losing my cool and calling you names in such a childish fashion. However, this doesn't validate your arguements! All he is doing is denying reality, speculating and confusing people who may be newcomers and don't know his biased mentality. I wouldn't apologize to such a misleading person. But anyway, it looks like you may have had some impact on him as in post #4610 he replied to you as follows: I accept the apology. Its very nice from you. As a deal I'll try to be more of an observer from now on than "stirer". I got tired by now anyway. And I have not "seen" a single message from him since then. Link to comment Share on other sites More sharing options...
Barnacle boy Posted April 22, 2009 Share Posted April 22, 2009 Okay, state the algorithm then using bounding box that will allow missile to go under the arms but allow hitting of the arm. How does the missile go under the arm, but hit the arm? Also, how much anatomical detail are you expecting to pack into this sprite? But anyway, if you want to start setting up collision with specific limbs you can get a workable approximation with recursive bounding boxes. Sure, it'll have a CPU cost, but you'd only need a few recursions to get a sound approximation, depending on the detail in the sprite (and frankly, most sprites on 8bit platforms don't have a hell of a lot of detail). Plus, the finer checks would only be called when a collision was likely, based on the results of the first bounding box test. If you were really keen to do that on the c64, I expect you'd use the hardware collision in conjunction with a software routine to determine which sprites are involved, as I mentioned earlier. I didn't misrepresent; I quoted EXACTLY what you wrote. From what I quoted, it's sufficient to conclude that you are talking pixel perfect collision. I'm afraid it isn't, because I wasn't talking about pixel perfect collision in that first sentence. Your conclusion was illogical. @Oky, I wanted to edit my last post, but it seems editing is disabled....... No wonder you want to defend Wolfram. You also like going back and re-editing your posts. Better to defend yourself first rather than others. It's okay to edit posts, but I was speaking out against people going back and editing posts that were already replied to and dealt with. I would have made it clear it was an edit, but thanks for your concern, Batman. Link to comment Share on other sites More sharing options...
Barnacle boy Posted April 22, 2009 Share Posted April 22, 2009 What this thread has taught me... C64 fan Atariksi Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 What this thread has taught me... C64 fan Atariksi buhahaha Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 Okay, state the algorithm then using bounding box that will allow missile to go under the arms but allow hitting of the arm. How does the missile go under the arm, but hit the arm? Also, how much anatomical detail are you expecting to pack into this sprite? But anyway, if you want to start setting up collision with specific limbs you can get a workable approximation with recursive bounding boxes. Sure, it'll have a CPU cost, but you'd only need a few recursions to get a sound approximation, depending on the detail in the sprite (and frankly, most sprites on 8bit platforms don't have a hell of a lot of detail). Plus, the finer checks would only be called when a collision was likely, based on the results of the first bounding box test. If you were really keen to do that on the c64, I expect you'd use the hardware collision in conjunction with a software routine to determine which sprites are involved, as I mentioned earlier. ... Cop Out. Of course, bounding box can a pixel size. Next time admit you are wrong and I'll respect you for being honest. If a sprite has moving arms or even static ones, you need pixel-perfect collision. Duh! >>I didn't misrepresent; I quoted EXACTLY what you wrote. From what I quoted, it's sufficient to conclude that you are talking pixel perfect collision. >I'm afraid it isn't, because I wasn't talking about pixel perfect collision in that first sentence. Your conclusion was illogical. You are illogical thinking bounding box the size of a pixel is not pixel-perfect collision. Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 I am still waiting for algorithm from Barnacle Boy for his pixel perfect algorithm that uses only bounding boxes. Where did I say pixel perfect collision is done using only bounding boxes? Quote please. Post #4693: "Using bounding boxes doesn't mean missiles have to go through people's legs and under their arms, unless you specifically want them to. Exaggerating stuff to try to make your point doesn't actually make your argument stronger, you know. And the c64 can do pixel perfect collision. " I wasn't exaggerating; you were by claiming using bounding boxes you can allow for missiles to still go under their arms or through the legs. a) I repeat: Where did I say pixel perfect collision is done using only bounding boxes? You still haven't shown me saying that. b) Of course you can allow for missiles to go under arms or through legs using bounding boxes. Just limit the bounding box to the actual body of the player character. c) My "And the c64 can do pixel perfect collision" was the beginning of a new point, which for some mysterious reason you trimmed. In fact, I said: ... Okay, state the algorithm then using bounding box that will allow missile to go under the arms but allow hitting of the arm. >And the c64 can do pixel perfect collision. Considering most games on c64 use code to check for collisions, it's a trivial matter to let the hardware collision detection trigger that routine, then have the routine determine which sprites are involved in the collision. >I find it amusing that you got all miffy over Wolfram quoting you earlier and then increasing the font size of some of your words for emphasis, and yet you so deliberately misrepresent comments made by others. How's that double standard working out for you, chief? I didn't misrepresent; I quoted EXACTLY what you wrote. From what I quoted, it's sufficient to conclude that you are talking pixel perfect collision. You are misunderstanding and falsely accusing. You are just desperately trying to find fault. Even your claim "it's a trivial matter" is subjective. The guts of the issue is how much CPU time it will require whereas Atari just reads the appropriate Player/missile/PF collision register. Just one sentence makes it clear: Post #4693: "Using bounding boxes doesn't mean missiles have to go through people's legs and under their arms, unless you specifically want them to." Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 At the risk of causing any more bickering, here's a nice little demo showing all 256 colors used in motion (albeit fairly lo-res). Apologies if this has been posted - I am a sicko who has read nearly every post of this thread, but my memory isn't that good! Stephen Anderson That's a nice demo as it definitely shows something that the c64 will never be able to do. Along with everything else I pointed out in this thread which recently joined C64 fanatics have not read as can be told by their repeating the same mistakes. Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy. Quoted for the truth. Quoted for being a biased sidekick. Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 If a sprite has moving arms or even static ones, you need pixel-perfect collision. Duh! no you dont. bounding box does perfectly well. most games use that probably for a reason... Link to comment Share on other sites More sharing options...
atariksi Posted April 22, 2009 Share Posted April 22, 2009 What this thread has taught me...... I'm so sorry you bought an inferior system (C64) and were mislead all this time thinking it was superior to an A8. Perhaps, when you are in an emotionally stable condition, you will take the rational points addressed in this thread and live a more honest life and won't mislead and misinform others (if you ever get around to reading this thread). Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 At the risk of causing any more bickering, here's a nice little demo showing all 256 colors used in motion (albeit fairly lo-res). Apologies if this has been posted - I am a sicko who has read nearly every post of this thread, but my memory isn't that good! Stephen Anderson That's a nice demo as it definitely shows something that the c64 will never be able to do. Along with everything else I pointed out in this thread which recently joined C64 fanatics have not read as can be told by their repeating the same mistakes. on both machines it takes 1 minute to show something the other machine will be not able to do, and neither example will prove much about the overall capabilities. Link to comment Share on other sites More sharing options...
Barnacle boy Posted April 22, 2009 Share Posted April 22, 2009 Okay, state the algorithm then using bounding box that will allow missile to go under the arms but allow hitting of the arm. How does the missile go under the arm, but hit the arm? Also, how much anatomical detail are you expecting to pack into this sprite? But anyway, if you want to start setting up collision with specific limbs you can get a workable approximation with recursive bounding boxes. Sure, it'll have a CPU cost, but you'd only need a few recursions to get a sound approximation, depending on the detail in the sprite (and frankly, most sprites on 8bit platforms don't have a hell of a lot of detail). Plus, the finer checks would only be called when a collision was likely, based on the results of the first bounding box test. If you were really keen to do that on the c64, I expect you'd use the hardware collision in conjunction with a software routine to determine which sprites are involved, as I mentioned earlier... Cop Out. Of course, bounding box can a pixel size. Next time admit you are wrong and I'll respect you for being honest. If a sprite has moving arms or even static ones, you need pixel-perfect collision. Duh! Obviously I'm not talking about making a bounding box at a pixel size. Is there something about the word 'approximation' that you fail to understand? And is your thinking truly so limited (binary, even) that you perceive the only options available as being a single large bounding box or pixel perfect collision, with nothing in between. Stop trying to push a false dichotomy to support your position. It's intellectually dishonest. >>I didn't misrepresent; I quoted EXACTLY what you wrote. From what I quoted, it's sufficient to conclude that you are talking pixel perfect collision. >I'm afraid it isn't, because I wasn't talking about pixel perfect collision in that first sentence. Your conclusion was illogical. You are illogical thinking bounding box the size of a pixel is not pixel-perfect collision. Again, who said anything about a bounding box the size of a pixel? You're really shameless, aren't you. Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 Again, who said anything about a bounding box the size of a pixel? You're really shameless, aren't you. you're just wasting your time with him, he will never give not even a nanomater away from his views. sometimes even the a8 fans turn him down for stuff like he's trying to prove a8 sprites are better than c64's Link to comment Share on other sites More sharing options...
landgraf Posted April 22, 2009 Share Posted April 22, 2009 I know from my early Basic coding that checking for key presses for writing your own synthesizer using the qwerty keyboard has it's own peek address for all keypresses that you can use and this address has nothing to do with checking the joystick ports 1 and 2 so it is a third address for checking ANY keypress If you check out the kernal code at $ea87 you'll see that any of those peakable (is that a word, btw?) keypress values are calculated by poking the row of the keyboard matrix to $dc00 and reading back the switch-states of each row from $dc01. There's no way to avoid the interference bewteen joystick movement and certain keys. Paddles are another thing though, as only the buttons go through $dc00/dc01, the adc-part is done by SID. And lightpens affect VIC registers, even though they use the control ports as joysticks and paddles do. There's some weird wiring under the hood, really Link to comment Share on other sites More sharing options...
landgraf Posted April 22, 2009 Share Posted April 22, 2009 Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy. Quoted for the truth. Quoted for being a biased sidekick. If you can't present it in poem-style, then you have no point! No, seriously, what Frohn stated is just how the more advanced C64 shmups do it. And the less frustrating ones use a hitbox that is a _little_ smaller than the sprite for the player and maybe one that is a _little_ larger for the enemies. I don't know though whether the better A8-shmups use hit-boxes or the collision regs, perhaps one of the experienced A8 hackers here can shed a light on this? Link to comment Share on other sites More sharing options...
Fröhn Posted April 22, 2009 Share Posted April 22, 2009 (edited) Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy. Quoted for the truth. Quoted for being a biased sidekick. If you can't present it in poem-style, then you have no point! No, seriously, what Frohn stated is just how the more advanced C64 shmups do it. And the less frustrating ones use a hitbox that is a _little_ smaller than the sprite for the player and maybe one that is a _little_ larger for the enemies. Yeps that's the main reason to prefer bounding boxes, but there are other scenarios where hardware based collision detection will not help you at all: Detecting collisions before they actually happen and a touching collision where no pixel covers another pixel (for example: game character standing on top of another sprite but not IN the other sprite). EDIT: Especially when you are actually "colliding" (as in: you cannot move past another sprite) bounding boxes are highly superiour. With hardware based collision detection you will move a bit inside the other sprite, then the collision detection will notice that there was a collision and the game then will move you back outside this sprite. The result is a very jerky collision detection with a bad look & feel. Edited April 22, 2009 by Fröhn Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 Paddles are another thing though, as only the buttons go through $dc00/dc01, the adc-part is done by SID. And lightpens affect VIC registers, even though they use the control ports as joysticks and paddles do. There's some weird wiring under the hood, really indeed there's a trick to read the state of the space key by only reading VICII registers Link to comment Share on other sites More sharing options...
Rybags Posted April 22, 2009 Share Posted April 22, 2009 Most A8 games rely on collision registers - they work well, and you can easily HITCLR and reread them multiple times per frame. Bounding boxes - well, it's the same 6502 code, so in such cases you want them, you can do it that way. I agree to a degree - one of my pet hates of old-school games is the concept of a single pixel overlap for 1/50th of a second killing the player. One thing that can get around that might be to require a persistent collision, such as over 2 or 3 frames but I doubt any games ever bothered with such an approach. Vic - space bar? I'd guess the light-pen registers might help there since the fire button is used to feedback the beam sensor, which also coincides with the Space key on the matrix. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 22, 2009 Share Posted April 22, 2009 It's easier on Atari to split graphics modes vertically with DL. takes 3 minutes on c64, 1 minute on a8. doesnt makes a real difference. c64 can also split with its method anywhere not just every 8 pixels like DL aarg... again... read before writing... http://www.atariarchives.org/dere/chapt02.php Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 aarg... again... read before writing... http://www.atariarchives.org/dere/chapt02.php I'm deeply sorry, must have mixed it with DLI's those are every 8 pixel iirc ? dont get angry if I'm wrong again Link to comment Share on other sites More sharing options...
landgraf Posted April 22, 2009 Share Posted April 22, 2009 Most A8 games rely on collision registers - they work well, and you can easily HITCLR and reread them multiple times per frame. Ah, thanks for clearing that up. One thing that can get around that might be to require a persistent collision, such as over 2 or 3 frames but I doubt any games ever bothered with such an approach. I guess head on collisions of fast moving objects might be missed that way, perhaps that's why programmers refrained from using that method. Apart from that this seems to be a quite efficient approach. Vic - space bar? I'd guess the light-pen registers might help there since the fire button is used to feedback the beam sensor, which also coincides with the Space key on the matrix. Yes. There was also a way to create a cycle exact irq by fiddling around with the CIA data port and DDR-registers to fake a light pen sensor feedback, but for the same reason that method failed if space was pressed (and there are easier ways to achieve stable irqs that require less code, anyway ) Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 22, 2009 Share Posted April 22, 2009 (edited) aarg... again... read before writing... http://www.atariarchives.org/dere/chapt02.php I'm deeply sorry, must have mixed it with DLI's those are every 8 pixel iirc ? dont get angry if I'm wrong again again wrong... http://www.atariarchives.org/dere/chapt05.php but I am not getting angry...with your unflexible hardware you are not used to have a flexible gfx unit... same happens when switching from Atari ST to Amiga... and to answer your question... yes... you can trigger DLIs via the Display list...so your 8 pixel example only is right when using DLI and 8 line generating display list command... so...when using DLI feature in f.e. charmode then yes...in general only triggered at the beginning... but you can walk "down" by doing STA WSYNCs f.e. or you can use POKEY IRQs to have interrupts on a special scanline or even on a special point on screen... many ways to go... Edited April 22, 2009 by Heaven/TQA Link to comment Share on other sites More sharing options...
Wolfram Posted April 22, 2009 Share Posted April 22, 2009 and to answer your question... yes... you can trigger DLIs via the Display list...so your 8 pixel example only is right when using DLI and 8 line generating display list command... so...when using DLI feature in f.e. charmode then yes...in general only triggered at the beginning... but you can walk "down" by doing STA WSYNCs f.e. or you can use POKEY IRQs to have interrupts on a special scanline or even on a special point on screen... many ways to go... not so flexible then in case of charmode. walking down will waste cpu time. so, charmode instruction will "generate" 8 lines. bitmap mode instructions will make only 1 line? or you can either ask for 8 lines or 1 lines of any mode? if not then how is this possible: QUOTE (Rybags @ Wed Apr 22, 2009 2:47 AM) * 8 pixel boundaries are irrelevant. Atari can have 3 bitmap lines, a character line, 2 bitmap lines, a character line. 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