Barnacle boy

@atariksi: Your rather broad comment "I rather have missiles going through people's legs and under their arms than hitting them" did not imply that pixel perfect collision detection was required. If you wanted to set up a scenario that clearly required pixel perfect collision, then you should have been more specific. I did not change my argument after the fact. When you claimed that I had said bounding boxes could be used for pixel perfect collision, I pointed out that I had not said any such thing and offered an explanation of how bounding boxes could be used to either prevent or allow missiles to pass through a sprite's arms or legs. However, now you're stating "The example of a 8-pixel wide sprite (on Atari) with arms requires pixel perfect collision." What example of an 8-pixel wide sprite? You're trying to retroactively redefine your original comment ("I rather have missiles going through people's legs and under their arms than hitting them") into a definite example requiring pixel-perfect collision. Why? Because your false claim that I said pixel-perfect collision could be performed with bounding boxes depends on it. More dodginess on your part, I'm afraid. Furthermore, I already acknowleged that recursive bounding boxes would have an extra CPU cost. As for whether it's 'not good enough for this example', that's debatable, particularly as the example itself wasn't clearly defined. Incorrect. That's where I explained how bounding boxes (plural) could be used to create a finer collision detection scenario if required. And at no point did I say it would match pixel-perfect collision (despite your many attempts to claim that I did). I simply said it could be used to detect collisions with specific limbs, while also acknowledging that it would be an approximation and that it would entail a CPU cost, depending on the complexity of the sprite. Nor did I claim it would match the Atari's pixel perfect collision. I don't feel the need to reduce everything down to a direct competition between Atari and c64. I was merely pointing out that bounding boxes are more useful than your post implied. OK, here are a few good examples: Yet I had made no mention of bounding boxes being used for pixel perfect collision. When I had made no mention of bounding boxes being reduced to a pixel size. Again, I had said no such thing. I had even made it very clear that I was talking about using bounding boxes for workable approximations in finer collisions, yet still you persisted in misrepresenting my comments. You could have argued that recursive bounding boxes would eat up too much CPU time. You could have argued that animated sprites would introduce too much complexity. You could have simply stated that it wouldn't be as accurate or as efficient or as hardware supported pixel-prefect collision. All of those would have been fair points. But instead you decided to take a dishonest approach and tried to twist what I had said. Wolfram was right. I am wasting my time with you, thanks to your deliberate attempts to misrepresent or misconstrue what I've said. Frankly, I'm happy to let this post and my previous one stand for my side of this joke of a 'debate'. I have better things to do with my time.

Not once did I say you can do pixel-perfect collision with bounding boxes. I understand you get quite worked up when replying to people in this thread, but do me a favour and stop lying. It's not cool. I am still trying to find the word approximate in the above. And you can stop making false accusations about "exaggerating" or being "shameless" unless you can PROVE it. I don't see any exaggerations nor anything shameless. You are the one who is exaggerating and being shameless thinking attacking someone with name-calling is going to help your case. In the post above I didn't go into detail about how to stop missiles going through arms or legs using bounding boxes, but the very fact I'm talking about using bounding boxes should already make it clear I'm talking about approximation rather than pixel perfect collision (as a separate but related point, I then went on to suggest that the c64 could to pixel perfect collision using a combination of hardware and software routines). However, after this post, you started claiming that I had said pixel perfect collision could be achieved using only bounding boxes. When I pointed out that I had not said this at all, you responded with: "Okay, state the algorithm then using bounding box that will allow missile to go under the arms but allow hitting of the arm". In turn, I explained what I was getting at in greater detail: ...and your reply was "Cop Out. Of course, bounding box can a pixel size." Which prompted me to ask you "Is there something about the word 'approximation' that you fail to understand?" So what do you do? Feeling that you didn't 'win' this point, you jump all the way to my first comment, where I said "Using bounding boxes doesn't mean missiles have to go through people's legs and under their arms, unless you specifically want them to" and then you try to pick me up for not using the word "approximation" there. Well here's a newsflash for you, Jonny Cochran: I didn't specifically use the word approximation initially because A) bounding boxes by their very nature involve approximation, and B) It wasn't a detailed post; I was just pointing out that bounding boxes aren't so restrictive that you can't create finer collision detection scenarios if needed. I didn't try to suggest that it's better than pixel perfect collision, or even that it was as good as pixel perfect collision. I merely pointed out that you can still have some control over whether legs or arms get hit or not if needed. This is not some outlandish unreasonable point, no matter how much you might like to imply otherwise. Honestly, I think you're possibly the most deceptive poster in this thread in regards to your arguing style. You kept stating that I had claimed pixel-perfect collision could be performed with bounding boxes, despite me pointing out more than once that I had neither said this nor intended to imply this. And when you feel you're losing ground, you start yammering about the "Chewbacca defence" while doing everything you can to misrepresent and misconstrue what your 'opponent' has stated, even if it means ignoring any further clarifications. You tried similar tactics when arguing with TMR about two monochrome sprites on the Atari being needed to create one multicolour one. So yes, you are shameless. I stand by that, and I think your posts serve quite effectively as a testament to that.

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. Again, who said anything about a bounding box the size of a pixel? You're really shameless, aren't you.

What this thread has taught me... C64 fan Atariksi

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'm afraid it isn't, because I wasn't talking about pixel perfect collision in that first sentence. Your conclusion was illogical. 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.

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: 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?

Where did I say pixel perfect collision is done using only bounding boxes? Quote please.

Thanks buddy! Thanks for doing that... just for me! But I liked post #4129, in which you said "He was stuck in a well and regardless of how many other frogs told him there's an Atlantic Ocean out there, he kept insisting there is nothing better than this well. This is the best. I cannot have any other better home." Remember that one? It really seemed like you were suggesting he'd be better off in the Atlantic Ocean! Hoo boy! We had some laughs about that one, you and me. Good times!!

@Oky, I wanted to edit my last post, but it seems editing is disabled.... Just to clarify, it's inaccurate of me to say the electron beam 'skips' every second scanline when displaying a non-interlaced image on an SDTV. I should say it draws each horizontal line one scanline apart (in much the same way as it would in one field of an interlaced frame). But as I've mentioned, it treats this as a full frame, with a framerate of 50/60fps, rather then being a half-frame or field, and of course the next frame isn't offset one scanline. Some pics might help illustrate the concept. These are taken from an SDTV. Top is Gradius III running non-interlaced at 60hz on PS2. Bottom is Gradius III running interlaced at 60hz on mame on xbox. You can see that in the non-interlaced image the horizontal lines are spaced one scanline apart, unlike the interlaced image in which all scanlines are covered (albeit on alternate fields). What the images don't show you is the perceptible flicker in the interlaced image, compared to the total lack of flicker in the non-interlaced one. Also, while the non-interlaced one is running at a full 60 frames per second, the interlaced one is technically 60 fields per second, which means that if you sat close to the screen you might see some 'combing' or feathering on the edges of moving objects due to two different frames within the game being presented on the screen as two interlaced fields. This doesn't happen with the non-interlaced display. Bear in mind too that the gap between each horizontal line is less noticeable in a non-interlaced PAL(50hz) image due to the higher vertical res. Here we see some non-interlaced text from Ico, first at 60hz (It's PAL60, but in terms of number of lines, it's the same as NTSC), then at 50hz. ...still, even at 50hz the scanlines are more visible than they would be in an interlaced image, but the bonus is that they have zero flicker, etc.

Like I say, that's where you're going wrong. When an SDTV displays a low res (ie: 240p/288p) signal, it is no longer interlacing two fields, and the electron beam is no longer exciting the phosphor on alternate scanlines. It's an actual progressive scan at 50/60fps, however it skips every second scanline.

As ijor has pointed out, where you're going wrong is in thinking that TVs of the time (ie: SD TVs) must always display an interlaced image. When you connect your c64 to an SD TV, the TV will display a true low-res, non-interlaced image (sometimes called Low Definition, also sometimes called 240p or 288p). Because the image isn't interlaced, instead of needing two fields to create a single frame, each field now serves as a full and independent frame - the trade-off being that the apparent vertical resolution is half that of a normal interlaced image and the scanlines are more noticeable. However it also means you can have true 50/60fps motion (with no combing/interlacing artefacts), and of course, no flicker. So... the key point is that in a low-res non-interlaced mode, it is no longer two identical fields interlaced together to create a full frame. It is now effectively two separate frames, hence allowing a true framerate of 50/60fps. And there are no longer 'even and odd scan line pixels', as the screen update is actually skipping every other scanline. As a point of interest, it's not just c64s and Ataris and other platforms of the time that can output a low-res non-interlaced signal. Most PS1 games used the PS1's non-interlaced mode (with a vertical res of something like 240px), and even the PS2 can output a true non-interlaced low resolution image. One example is Ico on PS2. If you play that you'll notice it has the typical 'fat' scanlines of a non-interlaced LD mode. Gradius III on PS2 is another example.

Oh god, why does everything have to be explained to some people... My "edit: TO FIX A TYPO. DON'T PANIC!" was to clarify why I edited my post, as certain people have been whining about others editing posts. (Hint: it was a joke.) I wasn't saying there was a typo in your analogy. My comment about your analogy is very straightforward (and somewhat tongue in cheek), but I'll say it again: Frogs can't live in the Atlantic ocean. It'd make far more sense to use a large freshwater lake as the Dr Frog's unimagined alternative environment.

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. 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. So it's not a case of 'we can't do it so we disparage it'. It's simply a case of pixel perfect collision being unsuitable for most games. You've used this analogy about fours times now, and you still don't seem to realise that frogs can't live in the Atlantic ocean. Fix your analogy, professor! edit: TO FIX A TYPO. DON'T PANIC!

Though bear in mind that with the 1541 you could flip the disk over to use side 2 for another 170kB of storage.Not the same thing - I wouldn't want to have to sit there flipping floppies over every time my BBS users changed discussion forums.

Yeah I know. I'm just pointing out that on a 1541 you could still use the full 340kB of a double-sided disk by flipping the disk.

Though bear in mind that with the 1541 you could flip the disk over to use side 2 for another 170kB of storage.

Man, that'll teach gklinger to give you information that he thought would be relevant to your purchase. Geez-a-lou, what was he thinking!? Well, you sure showed him!

Ah right, I hadn't heard that claim before. Normally I avoid A8 people...* *I kid! I kid!

Didn't 'forget.' Dwhyte specified the lowercase letters from a-z, so that's what I compared. No one was trying to claim the entire character set was identical.

The c64's lowercase letters are identical to the Atari's, no doubt about it. hehheh... nicking the Atari's font. That's kinda funny.

No one said "You're a communist" (although an Atari fan did label Jack Tramiel a communist). Earlier, Oswald remarked that speccys were popular in communist block countries. Also, when you criticised computers built with lightweight materials, Oswald joked that you'd "adore early communist pc clones. they are fuckin big and fuckin heavy using lots of materials. customers dont want anything but computers being 10kg heavy. yeah.. ". But that was obviously a joke. It was more a dig at the buying habits in communist block countries at the time than a dig at you.

Hmmm... I'm not sure if I'm reading you right, but interlaced images on the c64 aren't interlaced in the traditional PAL/NTSC sense. They're usually two separate MC images, offset horizontally by one hires pixel. Also, because the image outputted from the Atari/c64/NES etc isn't interlaced, the two alternating fields are positioned directly on top of each other and so effectively function as two separate non-interlaced frames, which means they can display true 50/60 fps movement (depending on whether it's PAL or NTSC). What I'm getting at is that it's incorrect to say you are just making use of what the TV is wasting every other scanline. In fact you are literally animating between two discrete frames at 50/60 fps, which means you are going to get a certain amount of flicker, depending on the degree of difference between the two images/frames. Interestingly enough, Rybags from this very forum was exploring a method to get a true interlaced image from the Atari. See here. It's pretty cool.

If you're so keen to play Hypersports in particular, then unless I'm mistaken a solid state card solution like the SD2IEC board for $45 should do the trick, considering Hypersports is just a single load game. Plus it apparently works with 300+ multi-load games. It's not a complete solution like the 1541 Ultimate, but perhaps it would meet your needs. Thanks. It's difficult to learn of these developments, if you're not already a C64 owner. Bear in mind I haven't used it myself, so I'd recommend seeking more info from other c64 users (frohn? wolfram?) before splashing out any cash. Maybe ask the friendly folks at lemon64 if any of them have used it.

There are heaps of c64 games that scroll colour ram. Certainly far more than you might expect judging by your comments. Bear in mind too that you don't necessarily have to scroll a 40x20 colour tile map to add a nice amount of extra colour. SEUCK, for example, has the colour map arranged in tiles of 5x5 characters, but even that still offers a fair degree of flexibility when it comes to adding colour. Anyway, here's a few games I could think of offhand that scroll the colour RAM, at least to some extent, complete with youtube links when available (unfortunately the video compression is pretty brutal on many of these vids). turrican 2 turrican Alien syndrome katakis rastan saga(not obvious on this level, more obvious on later levels.) Enforcer shinobi Creatures Ikari Warriors Phobia Operation Wolf Atomic Robokid <- Notice the 1 pixel high gap between the scrolling area and the score display. Obviously not impossible on the c64! There are many many more. It's not some kind of rare feature that's hard to find in actual games. Plus, as wolfram pointed out, even without scrolling, the colour RAM comes in very handy for colourful flick-screeners. Split screen horizontal scrolling is no big deal on the c64. Split screen vertical scrolling is much trickier. And as you can see with Rolling Ronny above, it's possible to have a split without many "empty scanlines".

Cool story bro. Considering the frog would DIE in the Atlantic Ocean, I guess that's one smart froggy.