Wolfram

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.

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

indeed there's a trick to read the state of the space key by only reading VICII registers

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

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.

no you dont. bounding box does perfectly well. most games use that probably for a reason...

buhahaha

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.

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. btw you forgot to pick about the fact that VIC2 collision detection at the case of multicolor sprites handles '01' non transparent pixels as transparent. I'd love to see you complaining through 2-3 pages about that

you cant be serious. bounding box collision detection is incredibly cheaper to do with cpu, than having to use the cpu to compensate for the missing width and draw that stuff by "hand". same goes for less wide sprites with more colors. it would be fucking (excuse me) stupid to do that.

I don't think they got of most of the restrictions that makes the C64 inferior to A8 to get C128. C128 still has restricted palette, not ANTIC based scrolling, gfx mode splitting, GTIA modes, simpler overscanning, 60-bits of collision detection (at pixel level for games like Popeye), 4-DAC audio, more restricted joystick/keyboard i/o, etc. I heard 128D had a better keyboard interface. C128 had a RGB output to prevent the pixel color shifts in 320 mode but it's still comparable to CGA graphics whereas Atari requires VGA graphics to display (beyond EGA). if you add up the pros and cons c64 is the superior. it can do the average 80's game scenario better than a8. big palette but unable to display more then the c64 vs smaller palette more colors displayable no HW scroll but can compansate it with cpu better than a8 can compensate for its inferior sprite system. HW collision detection - unused in most games 4dac audio - to use it u need all the cpu vs SID making hands down better music with much lighter cpu usage joystick/keyboard problem on c64 side - came across no game utilising both being not able to read them both without problems I/O - A8 wins for the standard setup

another of those features where the a8 wins hands down, but there's no real need/use for it.

it would be surely possible. on the c64 the supercpu is more of a computer on its own hence c64 bus cant be 20mhz, so it has to use own ram, copying its inner state into the c64 as needed.

c128 is a good choice. 99,99% compatiblle, there's a nice 128 demo as a bonus, and a some c64 demos use 2mhz mode on the borders to speed things up.

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

bullshit. exactly how many games use HW collision detection is not subjective. its a very hard fact. also it has nothing to do with non existing possible games. bullshit. he complained about the inability to put red green blue etc colors beside each other in effects.

now just picture a 2d stick figure. its not possible to pass a "missilie" through it's legs and under their arms, without touching any pixels. and even if it would be possible imagine the fustration, when your bullets misses the enemy sprite since "missiles" happily goes through legs and arms and most sprite shapes can be happily estimated with boxes, hence most games do that, and it works nicely.

nice!

Pure bulls**t. The VIC2 has been designed to be the most competitive sprite engine of it's time and that's just what it is. ... It's competitive but that doesn't mean it wins in all cases. There are many events in the olympics so just because you have a faster backstroke/freestyle swimmer doesn't mean you'll win all swimming events. Get the picture? Your logic is that when Atari shows it's better at sprite useage in vertical direction or in overscanned cases or other cases, you're going to show wider sprites at more resolution although the event calls for something else. So when we talk about collision detection of 60 bits vs. 8 bits + 8 bits of vagueness, you're still going to use your freestyle swimmer. P.S.: for those that don't know there's a C64 register for sprite detection called the "Vague sprite collision register": whenever a sprite collides with another sprite, it sets the bit for both sprites that collided. So if sprites #0 and #1 collide and sprites #4 and #5 collide, you end up with 4 bits being set. And now if sprites #0 and sprites #4 collide and sprite #1 and sprite #5 collide, it sets the same 4 bits and so on. So to calculate what collisions actually took place, you can do the following algorithm: eenie, meenie, minie moe catch the sprite that is colliding so if it's not colliding, you won't know but who cares if you let one go ... This made me laugh out loud. Thanks. when multiplexing HW collision detection is useless anyway. and why waste 60 precious bits on collision, when most of the sprites have to be software ones anyway... sprites instead could have been a byte wider or smth on the a8. or use those 60 register bits for a 16 color mode where each color is pickable from the 128...

yes, sprite overlays. I wonder why almost no a8 demo uses the 16 color modes? (I only recall numen's "doom" engine) guess having the same luma would not give as good results, as the monochrome modes. also there are hardly pixel effects, filled vectors, etc eventho the a8 is faster. can you show me a8 "newschool" demos gong for 160x200 and 3d stuff ?

this is only true if you want to have some kind of monochrome depth shading. otherwise just plain wrong. monochrome vs 16 color: what are you trying to say? turning what into what style, and what limits ? the c64 is much better at mixing gfx & effects btw: interlaced 2x2x16 below... the scrshot obviously "cheats" and the fx is dead slow, just before you complain...

sure there's less artistic touch, but the smaller scene explans that. simply the competition is not as hard as on the c64. you dont need to do that much for an a8 demo to stand out as on c64. that 16 shade 4x4 mode is really overused in a8 demos, but you have to understand that the cpu is the fastest in that mode, and its nice for texture mapping/etc effects

I guess players+pm's wont make up for the needed width to get a 2nd layer. light effect= right side of the twisting logo is darker its really nothing.

sure: btw, I'm the least impressed with the coca stuff, the rotating textured shit is the best could be done on a8 aswell and even better... bear in mind that in (8bit) demos shear cpu power what counts most and the a8 is better in that. except if you prefer music/gfx.

Ah... but if the 1541 is not to be judged by the speed of the default firmware, then the Atari is not to be judged by DOS I. its ok to compare the beefed up, or the default drives. but mixing would be no fair, right?