Atari v Commodore

[Atari v Commodore]

@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.

 

 

You are using Chewbacca defense if you change your argument after the fact to confuse things. The example of a 8-pixel wide sprite (on Atari) with arms requires pixel perfect collision. Then you want to concoct your theory of approximation of RECURSIVE BOUNDING BOXES which is no longer the original debate which Frohn brought about by declaring collision detection is easily done with bounding box. RECURSIVE BOUNDING BOXES requires more CPU power than one bounding box and it's not good enough for the example.

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.

 

 

Here's where you changed from bounding box to RECURSIVE BOUNDING BOXES. Post #4754. And it still has to boil down to single pixel bounding box at some point in the recursion to match the Atari's perfect pixel collision detection. Remember we started this debate comparing Atari's collision detection with C64s and Atari's collision detection is pixel perfect even if you misunderstood the example of missiles going under the arms and through the legs to be NOT pixel perfect.

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.

 

 

WHY DON'T YOU PROVE YOUR ACCUSATIONS. State all the posts that are deceptive.

OK, here are a few good examples:

I am still waiting for algorithm from Barnacle Boy for his pixel perfect algorithm that uses only bounding boxes.

Yet I had made no mention of bounding boxes being used for pixel perfect collision.

Cop Out. Of course, bounding box can a pixel size.

When I had made no mention of bounding boxes being reduced to a pixel size.

Unless you want to use Chewbacca defense like Barnacle Boy and claim you can do pixel-perfect detection using bounding boxes.

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.

[Atari v Commodore]

Unless you want to use Chewbacca defense like Barnacle Boy and claim you can do pixel-perfect detection using bounding boxes. Or use his other style of arguing-- just call people "shameless" for not agreeing with you.

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.

 

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...

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:

...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.

...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.

[Atari v Commodore]

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.

[Atari v Commodore]

What this thread has taught me...

 

C64 fan

 

 

Atariksi

[Atari v Commodore]

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.

[Atari v Commodore]

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:

 

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?

[Atari v Commodore]

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.

[Atari v Commodore]

Just for you I went back and found the post #4392 where I made it clear Dr. Frog was unable to imagine a body of water bigger than his well. But at least you understood the intent.

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!!

[Atari v Commodore]

@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.

[Atari v Commodore]

Whatever happens the electron gun on the CRT has no choice in PAL but to re-display each alternate line of [let's call them] hires vertical lines regardless of the resolution of the input signal (be it 256 or 512 lines down etc) every 50th of a second. So if you are on a 320h x 200 or 256v screen on the computer the phosphor dots on the alternating lines are activated with the same 'image' if you like on both fields each 50th of a second, as the pixels on the computer cross over the full PAL resolution.

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.

[Atari v Commodore]

...So essentially the even and odd scan line pixel on the C64 will always be the same as they encompass 2x2 actual screen pixels on the TV/Monitor screen. So to not do anything to modify the image between each field refresh (not frame) is a waste as the display is just showing two identical fields in succession otherwise to build up the full PAL resolution @ 25hz. So the TV/Monitors of the time (and Amiga/ST days too) are always displaying an interlaced image, it just happens to be the same two identical images for each field on a C64 or Amiga/ST in low res ...

 

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.

[Atari v Commodore]

>edit: TO FIX A TYPO. DON'T PANIC!

 

It's correct as it is if you understood the analogy from the beginning. If you can't understand the clear cut point, that's your problem.

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.

[Atari v Commodore]

Subjective. Let's be more truthful. Having hardware collision at pixel level is better than having little or no hardware collision at pixel level. Both machines can do bounding boxes although Atari is faster at it. I rather have missiles going through people's legs and under their arms than hitting them. Most sprites shapes are not boxes. A typical C64 biased argument-- if it's not in the C64, it's not that useful. For a processor that's slower, it needs more hardware to compete with processors running faster.

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.

 

Dr. Frog through his limited experience and attachments thought what use is the Atlantic ocean if it can't be shaped like my well.

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!

[Atari v Commodore]

The main benefit of the 1571 was twice the storage and faster speed.

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.

 

 

[Atari v Commodore]

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.

[Atari v Commodore]

The main benefit of the 1571 was twice the storage and faster speed.

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

[Atari v Commodore]

If your point is to "rain on my parade" with news that the 1541 Ultimate is slow, so be it. Wolfram will gladly point out to you how fast it actually is (I don't see you debating him). The point still stands that I don't have to get a lame-ass 1541 in order to get a Commodore 64, and that is exactly why I am doing it now. If that's offensive, I don't give a shit.

 

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!

[Atari v Commodore]

Sorry I misread his sentence. But from other A8 people I often heard that the entire font is ripped so I kinda expected that from him too

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

 

 

*I kid! I kid!

[Atari v Commodore]

You forgot the rest of the characters

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.

[Atari v Commodore]

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.

[Atari v Commodore]

- the c64 guys are mostly from Europe, and their insults ("You're a communist!") are so culturally irrelevant that its genuinely 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.

[Atari v Commodore]

There is no PAL artefacting, it is simple interlacing...and on a 320x200 image on a TV it will only display at 30/25FPS anyway because ALL TVs use interlace to display a picture and do 60/50 FIELDS not frames per second. Each field is identical usually on 320x200 rez so you are just making use of what the TV is wasting every other scanline.

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.

[Atari v Commodore]

-snip- RAH RAH RAH! -/snip- ...remember I want to play Hyper Sports and it's not on A8.... -snip- RAH RAH RAH! -/snip-

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.

[Atari v Commodore]

how many games actually scroll the colour ram, too???

 

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.

 

ok... Fire up Schreckenstein... play it! it has 50 Hz overscan splitscreen and mixing gfx modes (the score panel f.e.). and no flickering of rasterlines nor many "empty scanlines" between to trigger "Rasterinterrupts". Ah...and of course overscan...

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".

[Atari v Commodore]

He reminds me of the story of Dr. Frog in a well. 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. Such narrow-minded individuals are a complete disgrace to computer society.

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