Oswald

Heaven you are right, in fact my cock got hard thinking of your idea alone 50fps scrolling is quite a problem at c64 at certain scenarios. one of the "color attribute" rams can not be doublebuffered so either you stick to 4 colors, or reduce screen size, or engage in various tricks when you want the color ram be scrolled aswell.

as soon as you want to have huge tile based levels as turrican, you can forget about flexible scrolling methods.

dont know that 2600 trick. the deal is that next rasterline's sprite data is being fetched already on the sideborders, so you can make a 9th sprite which uses the next line's sprite data. but in the next line you still only have 8 sprite's data read, so you turn it blank, and always use one of the next line's sprite data for the 9th sprite.

not exactly. the trick is that the 9th sprites uses the fact that where it is displayed data is already fetched for the next row sprites. thats why every 2nd line is blank. and it has not to reuse pixel data.

80's type 2d games suits perfectly the c64. its not that they were designed for the c64. actually _most_ of the c64 games are to be found on other systems aswell, many of them coming from arcades or other machines. once you start doing tricks, games like turricans, last ninjas, creatures, mayhem in monsterland emerges on the 64. check them out if you havent already.

count the sprites at 1:40. http://noname.c64.org/csdb/release/?id=96 check the screenshot, more than 8 sprites multiplexed over an area where in each rasterline background color is changed 7 times. the sprites are moving, and some of the raster colors aswell. check the video, digis in there does work that way. http://youtube.com/watch?v=cQNT9Whg4r4

now I know why the c64 was more popular: because emkay scared off all the people from the atari

heaven, yeah it could be said that atari is better for demos, and c64 is better for games. on the c64 64k is usable except stack & hardware vectors at the very and of the memory (same on atari guess, as same cpu and 2 bytes 0000 and 0001 which are used for tape IO, and changing which roms are on/off. but guess you can turn off roms and have 64k in ataris aswell ?

thats not exactly 8 times the color depth, but 8 times the palette. in stock modes you have the same 16 colordepth (out of 128) , but in 4 times smaller resolution. this is DMA: http://en.wikipedia.org/wiki/Direct_memory_access. c64 and atari both uses it. nice stuff indeed, but I think c64 used the better compromise: doing sprites is much harder with the cpu, so the video HW supports sprites extensively, and lets the easyer per line regchange job done by the cpu. unless it comes to demos you only want to change screenmode / palettes just a few times on a screen. here is the demolist, all of them do their thing in realtime: phong/gouraud: http://noname.c64.org/csdb/release/?id=3394 phonged texture: http://noname.c64.org/csdb/release/?id=36663 gouraud in pixel res, wolfenstein clone: http://noname.c64.org/csdb/release/?id=11692 shading&texturing porn: http://noname.c64.org/csdb/release/?id=4605 2x2x16 textured cube at the end: http://noname.c64.org/csdb/release/?id=3585 aged coderporn: http://noname.c64.org/csdb/release/?id=4762 phong torus&texturing: http://noname.c64.org/csdb/release/?id=4761 gourad, texturing etc in pixel res: http://noname.c64.org/csdb/release/?id=4019 best filledvectorshow up to date: http://noname.c64.org/csdb/release/?id=11610 one of the very rare programs doing a whole 3d world: http://www.ffd2.com/fridge/lib3d/coolworld.zip

and it would be even more for the atari. 8 bit displays do blur everything together, not to talk about that PAL is averaging UV part of the YUV signal. (afaik) that means on a pal display you can mix out totally new colors. (any HW can do that using a pal crt) "complex" 3d scene, it could be done faster today tho, there was a better method for gouraud invented since then:

16 color is enough

hires+16 colors comes with a price: no 128 color palette.c) 128 colors comes with a price: with no tricks you can only display 16 colors of the same shade, or 16 shades of the same color, in very lowres. (iirc) its just a different compromise of the technique present at the day. you choose which do u prefer. what do you call a DMA ? C64's gfx chip uses quite a few hardwired different "direct memory acces" types for sprites, char data, etc, for which it stops the cpu, when its time to read the mem. c64 is almost twice as slow as atari in that gfxmode. run numen at 50% speed in the emu and check that fx again, and you'll know why c64 demos dont do that often . its simply slow. however there are a few demos which do complicated 3d stuff going as far as phong shading with texturing at the same time. let me know if you want me to list them tho prolly you will need emu (most of them are not on youtube). the other reason is the highres mania of most of the c64scene, the 3rd reason is simply that 16 shades of the same color simply look better than 16 dithered shades out of 4 colors, which the c64 can do (atleast i think so) again, I can give you a list. you are just lost in the mass of demos and what does that mean? I think the situation is quite similar: Both on Atari & c64 you usually start with coding your screenmode, when it comes to demos yes, but you have very little ram, and very slow transfer speed a few demos use it mostly to calc 3d coords. I think the situation is similar. the c64 superCPU to circumvent timing problems has own 64k ram, and it does mirror it with some mechanism to the c64. you can set it up through registers on how to do it, but I have no idea how it works exactly. The 6510 and the VICII chip shares the bus in a hardwired 50%-50% scheme and sometimes the VIC stops the cpu and steales even more time(char pointers, sprites) , which there is no way to change, otherwise the video timings would have to be changed aswell, meaning the entire VICII would have to be redesigned. dont think so, c64 was designed in less than a year including the chips. you can do whatever tho with the usage of the 'cartridge' port, as all important lines are routed out. guess its the same on a8.

"Well, it would be interesting to know how much of that "hi achieved" C64 demos simply do not run on NTSC machines due to the low cpu speed." and how much pal atari demos do not run on NTSC machines ? to start with low cpu speed doesnt makes anything not to run, it only makes stuff slower. just so you know: most c64 games are PAL/NTSC compatible, because the race for the points for making them compatible in the cracker scene made it a default thing that crackers fixed everything they got their hands on to run on both pal/ntsc. so you can stop crying about pal/ntsc.

2 issues of a c64 diskmag which is about the indepths of that era: http://noname.c64.org/csdb/release/?id=29897 http://noname.c64.org/csdb/release/?id=42400

try noname.c64.org/csdb/

this game has been developed for like ~10 years. not non stop, and not without some years doing nothing. but it has seen shitloads of work. there's a HDD version for c64 aswell. dont be fooled its not just the graphics you see. the story itself is very complex and very long aswell. you have many routes to solve things, you have conversations zillions of npcs, team members, items, wallsets... the homepage of the game seems to be down, already the screenshots are tiresome to watch through of all the gfx

w o w, what an ammazing programming lesson. all my hats down, and all my thumbs up and my dog's btw I more often than not fail into the trap of making it fast first, instead of working ) waiting for the next chapter.

well, crownland looks technically stunning, maybe the guys working on it can add a lot of extra little touches to boost playability.

better?

1982 CES: "The guys from Atari came by to look at it and said, 'They can't do that. It's impossible for the price.'" (1982) Atari 800 = $899. c64= $595 "The Atari 400 and 800 were very similar in hardware terms, but were very expensive to build, which forced Atari to redesign their machine to be more cost effective. This resulted in the 600XL/800XL line" "Aggressive pricing of the C64 is considered to be a major catalyst in the video game crash of 1983."

maybe some words on the maths ? optimization of the raycasting engie ? how would you do sprites ? shading? etc ? handle enemy data on the map? how would you do some active lighting? screenmode is really one of the smallest problem. its only a tradeoff between colors/resolution/speed. the main question is how to render fast.

why dont you code Call of Duty 4 or Crysis for example? here's how it could be done imho: decide wether 4 color 160x200, or some pmgs with dlis and color changing, or apac, or char mode, etc. then: 1. do the player movement 2. do enemy movement 3. update screen 4. do more stuff thats all, its really simlpe

yeah, the color memory is char based, so they have to align the walls to it to avoid color bugs, if adding more than 4 colors.

because the distance of the wall slices and the player is only constant in orthogonal cases. imagine the wall shown on the link in a rotated version. for a doom game you need the engine (vector?) from Numen with texture mapping. it would be around 1 fps or worse. textured floors needs more math as a rotzoomer alone fex.

yeah I am *that* Oswald somehow I have stumbled upon this thread and I found it interesting so... eru, probably you have to turn on "true drive emulaton". charmode will look like the speccy doom seen on youtube, because that one does that aswell basically just without actually having a charmode built in. imagine some more colors to it, etc and you get charmode doom on xl