I'm beta-testing a new AI. I am quite impressed by its ability to research and plan, and so as a test I asked it to write a chapter of a book about the TIA. Here's what it came up with; I am yet to proof-read it all, but an initial glance leaves me quite impressed both with the quality of writing, and the planning required to actually make this.

The prompt I wrote (including typo) was "Let's write a book on programming the Atari 2600. I want to work on chapter 1, describing the TIA chip and how it works. Please do taht."

I'm interested in feedback/comments on this.

Starting to become curious about programming the Vectrex.
Is anyone here already up to speed on that platform who might offer some tips?

On atari.io forums I have just noticed some discussion on Boulder Dash, and in particular some views and criticisms of my actions. I would normally reply there, but I don't have posting permissions and my application is taking too long to process so I thought I might as well post here while it's fresh.

My "antagonist" is in quotes...

Quote"The game really isn't Boulder Dash II, though.  The original BD II has different levels.  This new VCS version has the same levels as the original but with improved graphics."

The levels are not the same; they are unique to this version. The game is named "Boulder Dash 2", as in the 2nd Boulder Dash I have written for the '2600. The released version is technically "Boulder Dash 2 DEMO", but for space reasons on the title screen it says "Boulder Dash DEMO". It has never been referred to by me or BBG as "Boulder Dash II", AFAIK... and if it was, then it should not have been.

Quote"The programmer made a mistake. ...
It would have made much for sense if Andrew Davie made a true conversion of Boulder Dash II:"

Your expectations/desires/opinions don't align with reality here.  I had no interest in writing a conversion of Boulder Dash II, as I wanted to put in my own cave designs.

Quote"So only the first cave is the same as the first cave in the original, and all the other caves are different?  I wonder if any of the caves are the same as any from Boulder Dash II.  If not then again, simply calling it Boulder Dash is confusing because now it's just a hack of Boulder Dash"

Firstly, I think your idea of what is a "hack" is just wrong. In my world, a hack means you take existing codebase and modify it and more particularly the graphics and sound to produce a derived work. Boulder Dash 2/DEMO is a completely new engine, written from scratch. The caves are completely of my own design, including a "homage" to the first cave of the original (but completely different gameplay and more elements). The amount of work involved, compared to a "hack" is in a completely different ballpark, in a completely different country.

Quote"He needs to come up with a name variation.  Call it Boulder Dash Z, or Neo Boulder Dash.  Or even better, just make a VCS version of Boulder Dash Construction Kit."

I get it, you don't like it. I don't care. I don't "need" to change the name at all.

I think it's unlikely there will ever be an officially sanctioned construction kit, so that particular option was quickly ruled out of the question although it'd be lovely to have one. Unfortunately it could take potential income from the IP owners.

Quote"Thanks for clarifying that, Alex. But I have to disagree with your opinion about the levels in the new Boulder Dash being 'completely different'... With the new Boulder Dash, the layout of the interior walls are the same as the original, it's essentially the same cave.  The patterns you use with the original version would certainly have to be adjusted, but that would be minor compared to having to learn an entirely new cave layout.  If those minor changes are what Davie considered enough to make them new caves, that's just lazy on his part.  He should have either used the identical cave layouts, or created truly new caves (or used the caves from Boulder Dash II, or the countless hacks that have been done to the Atari 800 version over the years)."

The irony. I did create completely new caves. But also I wanted a "homage" to the first boulder dash so I used the same wall positions for cave A. But there are huge/significant differences in gameplay, and creatures in the cave. There are speed runs, amoeba, cavernous areas, tricky cascading blockages; all elements specifically added because I did not reuse the original cave data but instead designed a new cave format that allowed "additions/modifications" to base cave data. Each level is basically a common "theme" with per-level modifications on top.  So cave A has the basic wall layout shared, but then each level changes the rock density and positions, diamond density and positions, flags speed run or not, adds different structural changes (more walls, caverns), and creatures. For example, one of the caveA levels has an amoeba which quickly blocks one of the caverns. You have to plan very carefully how to mitigate the amoeba's expansion and not just collect diamonds in a set time. There are variations and although as I said it's a homage, it's actually just a "first impression" one. The levels are different; I know because I designed them all myself.

Interestingly you're not the first person to call my working style "lazy". Such comments amuse me more than anything; it really just shows that people don't understand the details of the games, the constraints, and the programmers' desires and intentions. I don't pay much attention to people who feel compelled to tell me what I should have done; at least it doesn't bother me. I've always done my own thing, in my own time, for my own enjoyment. There's this weird sense of ... shall I say entitlement.... That some have where they feel I should do things they way they wish/want/would and criticise me for not doing so. I don't owe anyone anything, especially as I release most of my work completely free of charge.

Quote"As for going to his website and asking him these questions, it seems clear he's made up his mind.  I'm not the one to change his mind, and the last thing I'm looking to do is waste time argue with the guy.  I haven't talked with him since I interviewed him."

I'm generally happy to answer questions. A difference of opinion does not an argument make, and I'm usually polite, if sometimes accused of being a bit gruff.

Quote"All I can say is, if you've read the interview, you'll know that at that time, he was programming for the VCS for fun, not to make money.  If he sold 100 copies of Qb, he'd consider himself lucky.  Well, he certainly sold more than 100 because it was popular enough that he re-released a holiday-themed version of Qb a few years later."

While the above is true, it is misrepresenting what actually happened.  At a best guess there were probably 400 copies of Qb sold over the years. We're talking 20 years or so. Yes, I did re-release a holiday-themed version of Qb, but I did not sell this. It was a free give-away for people who purchased some amount of items from AtariAge. I received no income/benefit whatsoever for that one; it was my gift to the community - and AtariAge for their support.

Quote"I did not say nor am I suggesting he owes VCS owners anything.  But I'll say this - to spend years on a public forum discussing milestones in his development of different projects and soliciting people's opinions and suggestions on how to improve them, and buildling up supporter's hopes of seeing them completed and released.... only to repeatedly abandoned them (and often w/o so much as a comment as to his change of heart; he'd simply go silent and stop posting about them) is completley disengenuous,"

Disingenuous, huh.  You're actually suggesting I was concealing my true intentions by not being honest and sincere. Do you really stand by that?  In any case, it's not true. I consider myself an artist, to some extent. A software artist, pushing the machine to the limits I can, and at the same time sharing my passion and work with others. Many come on board and help me out with suggestions, play testing, criticisms. I truly appreciated that. That's what made the community so great. In return, I "rewarded" many of those with public acknowledgement and thanks, free copies of my game(s), preview versions, etc.  The development blogs I maintained were extremely well liked and received, and I was generally pretty explicit that I did not promise completion, and we were all along for the ride. As an artist, some things you create work, some don't and are abandoned. Sometimes, most times, I lose passion in something. Occasionally there are technical reasons, but usually psychological reasons. Usually, life takes over and I have to abandon/stop work for one reason or another. But "completely disingenuous"... well, I'll add that to "lazy" as one of my many faults.

Quote"He (along with Jentzsch's help) created a truly wonderful tile-based game engine with his original Boulder Dash, which could have easily and quickly been adapted for use with many other games, and instead he wasted years fumbling with tweaking it."

No, it could not have been easily adapted. There were severe limitations with the bank-switching format that made it impractical for just about any other significant tile-based game. In particular, the number of characters in the "character" set was extremely limited. I think it was 15 or so, including animations.  I managed to do Sokoban, but even that was a stretch. And the very limited organisation of code in the static bank meant that it was difficult to add more functionality. A new bank switch scheme was necessary, which is why Thomas/I worked on designing 3E+ scheme and others.

Quote"The guy's behaviour at times is just baffling.  I'm not looking to analyze him, I'm just stating the facts of what everyone can see and read on Atariage for themselves.  I know there's a history now with him and Atari, and that he's the one stopping sales of the re-release of his original Boulder Dash (probably because that money is now split with Atari)."

Yes, I am not that predictable but trust me I operate on particular principles and not just randomly. The re-release of Boulder Dash came with a "trigger" that allowed any party (after an initial sales period) to stop continuation of the agreement. Because Atari purchased AtariAge, and that would mean I was in a business arrangement with Atari, my principles simply made it impossible for me to do anything but pull the trigger, so to speak. To do anything less would be hypocritical. It was nothing to do with money; well in fact I've lost out on any income so I'm hurting myself there. But as I said, matter of principle. I have zero idea if/how Albert decided to arrange the profits from sales with Atari. I haven't asked, and I don't particularly care to know.

Quote"I don't know all the details of that, but again, he could have worked out another deal with First Star Software years ago to either re-release BD or to make a true version of Boulder Dash II.  He didn't.  He complained about the original 250 copies being resold for inflated prices, as if that wasn't going to happen with a limited release (welcome to Collecting 101). "

It took many many months to get an agreement for those 250.  We were lucky to get that one up. That "he could have worked out another deal" is pretty much wishful thinking and that's just not the way things were. Thomas and I fought very hard to have an unlimited release, but we could not get an agreement to do that so 250 it was.

Since we've touched on my disapproval of resale at inflated prices, the best way I can explain this is that I do put a lot of work into my games/demos - way more work than I ever see in sales (or even thanks). Most people just take my work and I never hear a word from them again; not even a thank-you. But when I see people take my work and try to sell it for a 65000% mark-up (yes, 65000 percent) over what I received for that same copy... well, actually yes that feels disrespectful to me and the community. In capitalist USA that may very well be "Capitalism 101" but in some other parts of the world, artists are protected from such exploitation of their work. But that's another discussion and my view is apparently in the minority. In short, I don't like the feeling that I'm being "used" and will take steps to avoid that even at my own cost. I'll happily press the nuclear self-destruct every time.

Quote"He wants the community to praise his programming efforts, but he doesn't want to make money off of said efforts!  Do you understand him, Alex?  Because I sure don't."

I don't live in a culture that is capitalist above all else, or at least my worldview is not such.  Many things I do/share just because I enjoy creating things and it so happens that other people get enjoyment from them. I occasionally receive praise - which is welcomed and lovely. I truly appreciate when that happens; it's sad to have to seek it out. I get a fair bit of criticism too, but as long as it's well-meant and constructive then I welcome that too. Occasionally it's personal, but that says more about those people than me. Do I do things for money? - no, not generally. It's not my world-view, seeking money all the time and particularly profiting at others' expense. I like to give rather than take.

Quote"I'm not really understanding why BBG is limiting the number of FREE copies of a DEMO, esp with Andrew Davie now stopping any further VCS work."

That limit was their requirement. It took quite a while to fill the 100 places - well, truth be told I held a few back for various reasons so it's more like 95. Companies like FSS and BBG put limits on such things; we just have to live with that, as they are the IP owners and they do what they want with their property. But there's another side to this discussion; surely being thankful that there were 100 FREE copies for people to enjoy; this is not about depriving the community of anything. I just get this feeling in these sort of discussions of a sense of entitlement that people have; expecting to get what they want despite the wishes of those creating things.

Quote"I also don't understand why Davie would spend years developing a new kernel/engine, only to stop short of seeing it released as a final product."

Because I don't do these things for money. I do them because I enjoy them and find intellectual satisfaction in the challenge. I don't write Atari software for others; rather I write software and share my enjoyment and achievements (for free) with those who care to come along for the ride. Releasing things as a final product often takes a huge amount of extra work that for me, at least, is sometimes not necessary as I may already have achieved my goals.

Quote"I have to wonder how much Atari buying Atariage factored into his decision; if that was truly a deciding factor, there's no reason he couldn't continue forward releasing his games through someone else, like Champ Games."

100%, to succinctly answer your thought. And yes, I could continue writing and releasing through Champ Games or others. But at this stage I have zero interest in supporting Atari even incidentally by releasing software that runs on the platform. I do not believe they are good for the community. Nuclear option engaged.

Quote"Then again, he's always been a rather eccentric programmer."

This is probably true, but I'll take that as a compliment rather than a criticism.

Quote"Prior to his new Boulder Dash, he spent a year developing a version of Sokoban using his original Boulder Dash engine (https://forums.atariage.com/topic/293315-sokoban/) and spent 3 days toying with making a version of Minesweeper (https://forums.atariage.com/topic/295031-minesweeper/), neither of which were completed. "

Quite the itemised list of my work, presented as an implicit criticism. Nonetheless...

Sokoban was pretty much complete. Minesweeper was a quick "what-if". But the limitations of the original engine were a major major pain to work with, and I'd just discovered the CDFJ bank switch format which promised much improved development speed and ease. It made no sense, once I realised what CDFJ could to, to continue with any 3E bankswitch work. To top it all off, once I switched to CDFJ I had to start *defending* the choice of using an onboard ARM processor. That, to be frank, took a lot of the satisfaction out of creating new stuff. People were getting nasty (as opposed to supportive) with their opinions on what was legit, and what was "cheating". When the community becomes divided like this, it does somewhat take the fun out of things.

Quote"He then spent nearly a year-and-a-half developing a new Chess game that really showed some promise (and mentioned a lack of motivation several times: https://forums.atariage.com/topic/299157-chess/)... only for him to give up on it and claim over a year later it wasn't good enough and that he had other projects he was focusing on."

Yes, Chess was a fairly brilliant display engine but the game engine had limitations. When I realised what CDFJ could do, that the chess engine could be written in C rather than assembler, and that instead of 3+ years more work on chess I could use an existing engine for the moves and tack on my display system... it becomes clear that the 6502 implementation could never be good enough and compete with an ARM version running many times quicker with much more memory.

But you do touch on lack of motivation. Some of us "creative types" suffer from this - mood swings and depression. People who create things are not machines, and they do not need someone holding a whip over them to make sure they stay focussed and complete their tasks. Get real, this is/was a hobby for me. If someone came to me and offered me $X to write a '2600 game, I'd not be so capricious with regard to getting things out the door. There's a big difference between paid work and hobby stuff, although I have neither at the moment.  Chess was slightly different - once I realised that CDFJ was better, it still has/had limitations where the C code could not be efficient because it needed to be servicing the display regularly - making writing a chess engine within this scheduling requirement a bit messy. It really needed a dual-CPU board which I was fairly certain at that stage was just around the corner. That was spot-on - there are already options that do that. However, given the current situation with Atari I no longer have the drive or interest in Chess on one of these new boards. A shame, really, as the display still pleases me and it would have been nice to see.

Quote"Next was Wen Hop that was clearly some bizarre variant of Boulder Dash that he spent over 2 years working on before abandoning it (https://forums.atariage.com/topic/323162-wen-hop-the-search-for-planet-x/) and turning it into the new Boulder Dash."

You seem to have researched quite a timeline and have more details than even I recall. But the above is not quite correct. I started writing a Boulder Dash engine in CDFJ.  Then I thought OK, this engine and bank switching scheme is great - what game can I write? I used the new engine I'd written (with graphics from BD) to start develop a new game concept which morphed into Wen Hop. I still think it's a brilliant game idea. I changed it so significantly it is pretty much nothing like Boulder Dash anymore. Completely different gameplay, graphics, concept. But yes, it started out as Boulder Dash simply because I re-used the existing engine as a starting point. I do this with many/most games. I take existing code, cut out stuff, change graphics and slowly morph it into a new game.  At some point after working on Wen Hop, I then started a completely new Boulder Dash (AGAIN!) using the Wen Hop engine. I did this because Wen Hop had huge amounts of optimisations and engine improvement from the original CDFJ Bouder Dash I wrote.  So the sequence was pretty much switch to CDFJ, write Boulder Dash to see how CDFJ would do it. Morph Boulder Dash into Wen Hop. Start Boulder Dash from scratch again, morphing from Wen Hop.  So, Boulder Dash and Wen Hop have very similar engines but totally different gameplay/game concept.

Quote"And I seem to remember Davie had given up on the original Boulder Dash until Jentzsch offered to help him finish it."

Not quite right. I started Boulder Dash in 2003 or so, and shared progress on the forums. Thomas was a big Boulder Dash fan, and I invited him to collaborate. I'd already written much of the engines and systems that made it possible, but it needed a lot of work on efficiency. Thomas and I worked together, on and off, for many years on the improvements and slowly got it into shape. Every now and then life/depression intervened and I called a halt to the project. Many times Thomas was asked by others to complete it, but he always refused, insisting on waiting until I wanted to restart. He never badgered me, or tried to motivate me. But when I wanted t restart, he was there. Eventually we got it over the line. It was a joint effort and I appreciated very much working with such a brilliant programmer - although we did drive each other insane from time to time.

Quote"There's no question he's one of the most talented VCS programmers and he's pushed the limits of that venerable hardware beyond what anyone else has done.  He's also created some truly amazing demos using his Chronocolour technique, but he's like some other talented artists who, if someone's not there to keep them on track and focused on a goal, he'll just noodle around in the studio forever as 'feature creep' takes over and delays projects indefinitely."

Hey, you know that's actually totally OK. Artists are gonna do what they're gonna do. With creativity comes certain madness. If an artist "noodles around" well you know... that's totally their prerogative, and who is anyone to question that. Particularly where the artist releases their work for free.

Quote"In Davie's case, having unlimited resources that the current technology offers isn't a blessing, it's a curse."

Maybe. I did complete Boulder Dash 2. There are actually something like 20 unique levels I designed. The demo only has three installed. So, completed but not released, shall we say. The released levels are pretty good, though, and gives everyone who asked for the demo a decent game to play.

Well, I think I've addressed all the comments/criticism, and it's turned into a bit of a War and Peace reply. I seem to do that a lot; people don't seem to be able to cope these days and often call my replies "a wall of text". I'd prefer to leave it at that, but if anyone has any questions then ask away. Meanwhile I'm just gonna lounge around, be lazy, and generally disingenuous.

BBG Boulder Dash will cease being sold on AtariAge on December 12th 2024.

A little while ago I turned 60 years old. I don't feel 60 - that's old man age!

But, turning a certain age does give one pause to think about "what's next", and what one's true priorities are. I feel like I've been central to Atari 2600 for almost 30 years now, that I've been a significant contributor in helping keep the platform remembered, relevant, and loved.

I adored creating new and interesting graphical effects and "showing off" my work. I also loved helping others program the machine, and sharing my knowledge. Over the years I've seen brilliant programmers come and go, who have left me in awe at their prowess and creations. And I've forged partnerships with some in various fields of Atari 2600 hardware and software. It's been a great pleasure working with Thomas, seeing ZPH thrive and survive, working with Wolfgang on the PlusCart, Rob on the MovieCart, seeing Albert build up AtariAge into the behemoth that it became - Bomberman for his testing, and many more. How could I forget JetSetIlly - and his amazing Gopher2600 emulator, which it has been my great pleasure to be a tester for. Apologies if I haven't named you all individually - there are so many over such a long time. What a great community of people.

And of course, I've had very unpleasant dealings with Atari the company. I'm not a fan. They did offer an "apology" which I found superficial, insulting, and self-serving. Pretty much the ubiquitous "straw" for me; they could have fixed things with a bit of genunie sincerity, and at no cost. So sad.

I am delighted to have as my last formal "release" the "Boulder Dash 2 DEMO" that I did a few months back. It's got some nifty stuff happening. Although benefiting from ARM on the cartridge, I still feel it is a genuine '2600 title which used the TIA in innovative ways to create amazing gameplay and graphics. That one will be my legacy, I think - although very very few people seem to know about it. Probably because by that stage I had abandoned AtariAge forums.

Writing such software is not easy, but of course nobody owes me anything for doing so. I did that sort of stuff for my own enjoyment. And yet, the feedback (or even "thanks") I received from those recipients was minimal. And I kinda feel hypocritical for saying that - on the one hand yes I do it for me, not for plaudits -- but on the other hand how much do you give before feeling you're being "used". One has to ask "why are you doing this stuff?" So, with that said I think anyone reading will realise I've decided to retire from Atari 2600 development. Call it an extended break, if you like. But at this stage it feels permanent.

I'm putting this out there in public because I've had a few enquiries asking if I am OK.  No, I am definitely not OK really; this feels like a loss of a longtime friend to me. But it's time, I'm pretty sure.

AtariAge thread on Cubix (2021)

Now that the 3D engine is approaching "maturity" and I have a pretty good idea where the bottleneck is, it's time to bite the bullet. I've used floating point calculations so far and it's now time to move to fixed-point instead. This will take me some time, but I expect the results to be dramatic. The stm32g070 uses software libraries for floating point operations (!!) and does not have a floating point unit (FPU). Imagine how much processing power is sunk into the 3D calculations - no wonder it's slow.  Clearly the bottleneck, and I predict a... let's say 10x speedup in the pipeline when I'm done. That would mean I could, say, run 100 space ships at 60Hz. Well, that's the dream. Watch this space, I guess.

Cubix

iCC3


iCC1

Spaceships on a Starry Night
with apologies to Van Gogh

In this rather long video I'm demonstrating the much improved stability of the 3D engine. Here it's running 10 spaceships. Previously I had been displaying only the back-faces (!!!) of the objects, so things were kind of warped and weird. Now that's fixed -- I kind of stumbled on this issue and am glad to have it working.  I have also found/fixed an issue with crashes which was caused by trying to render pollys that had been classified as "off screen". This lead to infinitely long lines being drawn and consequent overtimes.  There really isn't a lot of time available to do all this stuff - it all happens in the overblank (overscan+vertical blank) of a TV frame.

A long time ago I wrote a Rubik's cube 3D demo using CDFJ format. I was endlessly frustrated with my hand-drawn attempts to represent the cube rotating at various angles. It occurred to me that a 3D engine should be able to draw a 3D Rubik's cube - and so that's what I'm playing with at the moment. The thing is, to draw a cube correctly - the objects (26 or 27 little cubes) need to be drawn in the correct z-depth order. Currently the 3D engine does not sort the 'objects', and so it's a royal mess.



So this is a good test-bed to get the sorting functional.

I also "found" the cause of previous crashes - it's something to do with "big lines" in the 3D calculations. I limited the lines to 100 pixels just as a diagnostic. Now I don't get the crashes, but I do get the really odd/awful patches of solid colours on the screen; indicative of bad lines. But at least it no longer crashes. Debugging is difficult at the moment because I'm not setup properly with Gopher to examine variables or do profiling. All of this is old-skool with a value or two printed on the screen.

So, next step required for the cubes - a depth-sort of the transformed object position and then to render in that order (painter's algorithm). We should see a dramatic improvement in visuals when I get that up and running in a day or two.

Not really a dogfight. But the single ship in this version every now and then randomly changes direction and speed. It's quite interesting just keeping it in the "crosshairs"; I can definitely see a 1-on-1 dogfight working with this display system. Maybe WWII aeroplanes in the pacific, with an appropriate sky/sea background.  Anyway, just a bit of fun.

This is a .ELF file which will run on Gopher emulator or PlusCart. My process for making .BIN appears to be broken at the moment, but the .ELF works fine.

It will most likely crash if you let the spaceship go offscreen and/or behind you. So, don't do that! Also no need to report any crashes/glitches TYVM.

What is shown in this video works on real Atari 2600 hardware. That is, if you put this on a cartridge, plug it in, then any genuine Atari 2600 will run it. It will work just fine on a PlusCart with latest firmware. Please read my forum for details on implementation - the PlusCart provides an ARM chip on the cart which this demo uses for the 3D calculations. The '2600's TIA hardware chip is doing all the display for the TV; that is, the picture you see here consists of just one colour per scanline, 40 pixels resolution for playfield, and uses the two 8-pixel wide sprites and multiplexing.

Shown here is a few resets and random ships (3 of) while I variously rotate the camera and move forward/backwards. The ship positions change as expected, and all the scaling and rendering appears to be working correctly.

This was a particularly hard task for me and took some time. Although we have an ARM, there's only a small amount of time per frame available for the ARM to do its stuff - and all the code is written as a sort of cooperative multitasking behemoth - for the ARM chip also needs to service the 6507's request for bytes from the ROM. We don't have interrupts running; just a polling system. Timing is critical.  Aside from all that, just getting my head around the correct 3d processing math has taken me some time.

@Piledriver over at AA posted an interesting "x-Ray" image of some ROMs. Neat idea; I asked ChatGPT to write a Python script to do this for me. 20 seconds later, here's Boulder Dash's X-RAY. I jiggled a few pixels so you crafty people can't reconstruct a viable ROM from the image



It's clear that the ROM is totally chokka!

Here's a preliminary sound system. It's clear now where the emulation is slowing down - the sound does vary noticeably. On the plus side, it's pretty cool pressing the button to change ships and the explosion sound triggers.  This should work just fine on hardware, I imagine, without slowdown.

I've also added some diagnostics onscreen - the text at the bottom. This will make debugging things just a little easier.  This video is shown at the highest resolution (ICC1) - it runs much faster with lower resolutions because of less pixels to draw. But the systems are written to cope with whatever resolution you choose (ICC0,1,2,3) and appear to be working correctly.

Finally, some on-screen diagnostics. Debugging to date has been complete guesswork and colour flashes; this will make a huge difference. I should also get the symbols included in the gcc build so Gopher can display them. That will make a huge difference. But for now... we have numbers!

Although it seems a while since the last update, a lot has been going on behind the scenes. I spent some amount of effort moving towards matrix math because "that's the right way to do 3D math". Well, that was a poor choice. Yes, it simplifies code - but adds horrendous overhead compared to fine-tuned by-hand coding. The reason is, many of the matrix operations consist of matrices with lots of zeroes - because such elements are unimportant. But to do a full matrix 4x4 multiply by 4x4 you end up doing a LOT of floating point calculations. At one point I believe I counted 192 floating point calculations per vertex. Yeah, of course I'm not super efficient in my code yet, but it was clear that the manual way I was doing it originally was going to be way faster.

So, I reverted.

There have been a lot of behind-the-scenes work done in world-view, object-view, screen-view translations rotations and projections done - not quite ready for the big time yet. I got it working in matrices but as I said - way too slow. I will get that sorted soon.

Other things I've fixed is making sure everyting works and auto-adjusts aspect ratios and various buffer sizes based on the iCC mode used (iCC = interleaved chronocolour). So now I basically need to set a flag to one of ICC0, ICC1, ICC2, ICC3 and it will display in the correct mode.

ICC0 = (original chronocolour) = 160 x 64
ICC1 = 160 x 192
ICC2 = 160 x 96
ICC3 = 160 x 64

There are four binaries attached - obviously named - running the ship viewer in the relevant mode.

Another thing I changed is the fine-tuning on the throttle for drawing. It may still black-screen crash on hardware - but as yet I've not seen any issues running on Gopher.  I pre-count the number of "draw operations", where that means either a pixel write or a "block" write (a block being a group of 8 pixels of the same colour). Essentially the current settings/throttle is to do up to 11000 of these operation per overblank period. the code is highly optimised. When there's not enough time (when things are close, for example) the frame rate may drop - although it's not really noticeable in these demos.

I have the colour "palette" cycling in these binaries - about every second or so.

As before, up/down = move closer/further.
button = switch to next spaceship

I thought I'd share the "workflow" of installing a new ship. First I grab the raw data, put it through the AI-generated tool to identify the clockwise faces, then do some manual editing of the data to place into structures in my engine. Finally I go through and change the face colours one by one until we have a finished ship. This particular ship has unusual faces so it does show up the fact that I'm not sorting faces at this stage.

Glorious...  this is a "ship test viewer" that lets you cycle between the installed 3D objects (joystick button press) and zoom in/out (joystick up/down).  This is using a newly-rewritten rendering pipeline that works on a poly/face level rather than an object level, giving finer granularity in timing. So, things can now get full-screen (although not fully-tuned so expect an occasional crash)...

This is an extended rendering test with random generation from the (current) 12 spaceship pool of shapes. Emulator (Gopher) was running this mostly full-speed, although I can get extra real speed by a bit more finesse in the rendering code. It's still pretty impressive, though.  Of particular interest to me is that some of the objects (the "death star-like" object) get pretty much full screen and the system is coping well with this.