sack-c0s

having read the last page of this thread I've been trying to think of a way of getting through to Emkay, but I think a quick game of catchphrase is realistically going to be the only way forward. Just say what you see: now take *that* and put some PM sprites over it.

Because you'd just armchair coach the hell out of them and they'd get pissed off and do something they find more satisfying instead.

I never got on with eclipse - its always felt a bit slow and like the coding equivalent of running through treacle. Then I find other 'specialist editors' are eclipse in disguise, only nobody has customised the way they store their configuration so they nuke each others setup. Ultraedit feels like a nice balance of fancy features and being quick and useful. Compared to the other editors mentioned I think the only reason to choose UE over something like crimson is familiarity. Its probably not worth switching to it.

So we're all using eclipse these days? Damn - I feel like such an outsider around here because I prefer ultraedit.

oh dear emkay - you appear to have missed the challenge to code something to prove your point about C64 coders having little intelligence and the C64 itself being so easy to code for anyone can do it. Would you care to correct this little oversight?

If you want to pound away at a librarian be my guest, but this is hardly the place for discussing your kinks and fetishes

I don't think anyone was really ragging on the C64 guys initially - it was more a case of 'if they can do this with a C64 then what could they do with the A8? someone should dangle one under their nose and get them interested' type banter. Then Emkay turned up and pissed in the thread again with his comments about housebrick-sized pixels, despite advocating the same approach to optimise freescape in another thread. A classic case of why very few C64 folks find their way here.

What kind of interactivity would you expect? pretty much everything that was in the original freescape game. Hm... As there are nothundreds of enemies moving around, just some puzzles to solve.... Where should be the handycap? The 3D world in numen is doing more yet. Or at least it *appears* to be doing more - that's what democoders do It's not so much the overhead of game logic that could be a problem, more that a demo has a constrained and controlled view of the 3D world allowing you to optimise the calculations for the very specific cases that occur, or even completely precalculate it in some instances. In an interactive game you can't rule out cases without restricting freedom inside the game, so a lot of optimisations may either be impossible or any precalc data tables may be huge to cover the extra possible cases. I've not looked too closely at freescape so I don't know how fast it is or isn't from a code point of view, but I'd be surprised if there wasn't at least something that a few years of learning and progress couldn't improve upon. the framebuffer format and CPU speed alone should give a fair improvement. I wouldn't really take a non-interactive demo as proof of what would be possible in a game though. The truth is somewhere in-between, hopefully closer to the demo framerate.

What kind of interactivity would you expect? pretty much everything that was in the original freescape game.

can i still do it at the framerate you have in mind and still be fully interactive?

What tomfoolery is this?? That doesn't sound like the RadioShack I know. Surely you mean you asked for some computer help, and he said "Um...I don't know. Would you like to buy a cell phone today?" My first computer was a commodore 16, shortly to be replaced by a 64. My BASIC debugging was done by a mechanic in the garage where my dad works. Not once did he suck air in through his teeth and say 'that'll cost you...'

I'm lucky because I've never really needed to make a career choice because i was definitely one of the masses and with the C64 being as chap as it was I ended up with one and the fun somehow ended up evolving into a viable career path. I've gone on from hammering VIC-II graphics registers for fun to hammering powerVR registers for profit and it wouldn't have been possible without his attitude. Regardless of the minor details and the 'who got screwed by Jack' debates my life is a lot better for his work. So thanks for everything.

isn't the tradition that if you do it past midday then you are the fool? I spy a 3PM timestamp

that would all make sense especially as with sprites you can cheat a bit, and tie the 2D screenspace movement of a 3D object to the vsync interrupt and do the rotation updates as quick as you can in the main loop, giving a further illusion of smoothness. This demo (and probably loads more - this is the first that sprung to mind) does it - http://www.pouet.net/prod.php?which=9842

ahh - I wasn't seeing that. Probably better if I watch it in HD, but the office connection isn't playing ball at the moment

I think the tearing is down to running an emulation of a machine that is doing 50fps on a display that is probably doing 60, then cutting down to a video at 30fps. I'd reserve judgement until after seeing it run on a real machine I've hacked some of my code on the PC to capture through kkapture at 30fps and youtube still makes it look like a mess and I *know* that is frame-locked and should not be tearing

I think you're misreading what he meant. When a magician creates the appearance of the impossible the accomplishment is the trick, not actual magic. In other words, making it look like an 8-bit machine can throw polygons around at 60fps is impressive, but you shouldn't assume a technique was found for fast polygon games. Also, I wouldn't say all demos effects are smoke and mirrors, some are just interesting applications of the machine's native abilities. this. Even though it's a trick it's still a pretty clever and artistic thing to do

Is rasterisation even the bottleneck? I would've thought the 3D maths itself would be quite a heavy load and depending on the complexity of the object could account for more of the CPU usage than the actual drawing

That is what has been done on the A8, but that gives the restriction of a "moving object without background graphics". Unless the background graphics were composited in all the source buffers. The buffers have to be there already, so why not? actually I just thought that on the C64 if you built the 3D object into sprites, and switched the sprite pointers each line you could do it the A8 way and evade the compositing issue completely

And if people tried to read what I'm writing I'd really like to appreciate, people would use "all the magic tricks" to push the A8. But, as you may have recognized... it started with Rescue on Fractalus, and ends up with today's demos. The frames get finalized, then the "buffer" gets used.... step by step. Using the "unfinished buffer" with parts of the old buffer in a predefined way, the animation gets faster. Depending on that, you get 30-50% faster, you also get this motion blur effect, or you get additional movement reception to the eyes, giving the illusion of twice the speed... The Question is: Does the C64 offer some special feature that makes it easier to use that? Because it has been used from the beginning. And, well, we have some demos using direct screen drawing, without double buffer, but this doesn't enhance the movement, because it isn't controlled". That trick would actually be easier to do on the A8, because you could skip the copy and just rebuild the line addresses in a displaylist - the fact remains that to do this particular trick you do need to render every animation frame in it's entirety. The only 'cheat' is that instead of copying directly from a single buffer to get a straight cube you pick and choose across all of your buffers to create the bending rubber effect. It doesn't cut down on overhead at all - if anything it introduces a bit more logic overhead

everything is a cheat. a demo is one big smoke and mirrors magic trick. Unless you're raytracing at 60fps of course, and I'm sure all the honourable people are doing that right now.... of course if Emkay ever coded a demo he might appreciate that.

Just have a play with various machines, throw some routines together and eventually something starts looking like it might become a game on one of 'em. Then just go with it. My 8/16-bit machine of choice at the moment is the Amiga, but sooner or later I at least want to do something on all of them...

Si conectas la caseetera al Supercharger no puedes cargar juegos por los 400/800, además no puedes cargar juegos del supercharger con el Atari 400/800. Estas maquinas son demasiado diferentes - en muchos respectos los dos son iguales, pero la mapa de la memoría es bastante diferente, y los 400/800 son mas avanzados. (Lo siento - tengo un nivel de español bastante bajo. Aprendí Español cuando viví en españa 2 años antes, pero he olvidado un motón de vocabulario y cosas así...) everyone else: If i can make the effort to write that - you can make the effort to paste it into google translate (assuming I haven't buggered up too much and confused it )

so nobody is going to write it, nobody is going to document it, and people are going to make it awkward to gether information by turning every suggestion or request into bitching that nobody has done anything and skipping the question altogether? Sod this - if anyone wants me I'll be buried in my iOS devtools...

I would do things driver-first, but the reason I asked about editor layout is because that would imply what he wants to control and edit and how he sees that happening. That would then filter down into the layout of the data and the driver itself. I'm more concerned with what values he wants or needs control of and how fine-grain rather than a choice of screen colour or font