selgus

Old post, but still got some Suicide Mission shrink-wrapped boxes left. Thanks. --Selgus

I still say cut up a 130XE case and "fab" your own enclosure. I have two empty shells you can use, if you wanted to try. --Selgus

I'll have to check, when we were building XBAND for the Genesis, we had schematics for all the Genesis versions. --Selgus

Actually Nintendo has a policy about not allowing patching of game applications. The reason they give to developers is because of security reasons. We wanted to use patching in one of our Wii titles, to allow incremental feature addition via an online connection, but Nintendo wouldn't allows us to do so. Each year at the developers conference I have this same discussion with the execs at Nintendo, and they won't budge. --Selgus

Pigula doing IDEa? I'll have to ask him when he replies to my email asking for two spare SIO2SD PCBs (been waiting about a fortnight). I have one which I bought to use on a new Atari I had purchased, but never got around to opening it. I'd be willing to part with mine, being in new, unused condition, so that someone else could get use out of it. --Selgus

AmigaOS on micros TOPS-20 on minis --Selgus

Even more bad then that we won't see the code soon. Its always cool to learn some new tricks from other experts. Maybe some interesting code snippets? I hope in a few months or years, you will change your mind, Scott. I will wait. Well you guys have got him talking here already, and you now can see he is currently designing/fab'ing his own PCBs... seems like a pretty good start to me. --Selgus

Scott is one of the most talented programmers I have had the pleasure to work with. He is able to work at the lowest levels of the machine (as obvious from his 2600 work here, but you haven't seen a lot of his PS2 vector processor coding), and the next minute work/design higher level APIs. He stated this was not about the money, and I can support that.. as long as I have known Scott, it has been about doing things with tech that other feel can't be done, or is too difficult. Good to see you here old friend. Very impressive work... once again. --Selgus

I have been avoiding getting involved in this one, for various reasons, but really? I just have to scratch my head at some of these posts. It has become very obvious to me that people really do not understand what EA's servers do/cost and why they have them (besides being as stated, "Greed"). --Selgus

I have the framework for the main viewport and HUDs all coded up, with the fractal algorithm using P/M for lines and PF for the filling of mountains. Fractalus is more of a prequel to RoF, still am (was) working on much of the gameplay, instead of just a tech demo. It is currently using the E7 bankswitching protocol, with the RAM 0 being used for the bitmap-like display for the main viewport. Just very time consuming, and iPhone has taking the front burner now. --Selgus

Understood. I too had to put other projects ahead of the Fractalus 2600 game I've been working on. Want to finish up this iPhone/iPad engine/game before thinking of returning to the 2600. Squeezing stuff into the 2600 does take a large time commitment. Good luck on the racing game now. --Selgus

Does that mean Ballblazer has been put on the back burner now? --Selgus

This thing would have been really useful back in the day when I was doing Genesis development. The card I have cost me $1000.00 way back in the '90s and was connected to the PC via a parallel cable. I wrote a command line debugger for it under Linux, which would probably be pretty easy to port to this new dev hardware. --Selgus

If you are talking about console games, the "final say" is with Microsoft, Sony and Nintendo. Each publisher has their own QA departments and processes before releasing a game to the console manufacturer before they do their pass. --Selgus

At Catapult, when we did the XBAND modem, we needed to keep two free-running Genesis consoles in sync. The approach we took was to sync the VBLANKs. We would exchange small amounts of sync information every 1/60th of a second. Now, because no two consoles are exactly alike, the consoles would drift out of sync. We used the fact that you could switch the Genesis in and out of interlaced mode, thereby changing the time spent in the VBLANK. We would use this fact to have a sliding window that kept the two consoles in sync, by adjusting when we would switch in and out of interlace. So the algorithm keeps the consoles in sync from the standpoint of the data they exchange, but the consoles are never exactly cycle in sync. --Selgus

I haven't released it yet, so still a WIP. It uses the 3D endpoints of a grid to generate fractal lines that make up the 3D viewport mountains (player/missiles along with playfield graphics). Mine also updates the calculations every 3rd frame (so 20Hz), though the display is rendered every frame. I do the viewport calculation in 1/60th, HUD updates 1/60th and then game logic the last 1/60th. I'm currently using 1K of RAM for doing the double buffered 3D viewport and the fractal structures, and the 256 byte RAM windows for the HUD structures... though the original plan was to create my own banking selection on Harmony, to allow exactly what the game would need. --Selgus

I assume you mean ppcasm? Yes, my mistake... thanks. --Selgus

I use a mixture of 8-bit/16-bit arithmetics in Fractalus, where the perspective work is done in 16-bit until the high-byte is zero, and then switch to 8-bit operations. This along with table driven multiplies/divides allow the 6507 do the job. For my game, just the grid endpoints need to be operated on, so the data set can be kept to a minimum, coupled with not actually doing a full rotation matrix to bank the 3D view, but to shear the values. BTW, excellent work here Thomas! --Selgus

I was going to port some of my cpu-only n64 code to the HS at some point. Got one of these consoles but have never even opened it up yet. Has anyone else (besides opcode) done any additional homebrew on the console in the last few months? This is lower in my queue, but interesting nonetheless. --Selgus

I think this is quite funny! I just wonder... do people actually like the original game? These are going to fly off the shelf because of the production value, not the gameplay. --Selgus

Well the iPhone has similar issues, as I am writing my 3D gaming engine on that platform and need to deal with devices that have POWERVR MBX(3G) and POWERVR SGX (3GS). On the MBX, it is opengl ES 1.1 with a fixed function pipeline, and the SGX can also run opengl ES 2.0 with a programmable shader pipeline. How you do your rendering engine is very different depending on which version of ES you are targeting. I check during runtime and use the best interface that is available on the device, which means I need to code both ways of doing things in the application. Each one has different performance/features. --Selgus

After the Atari ST, Xanth Park had worked on an Atari 8-bit computer version. it used a pretty small viewport, but was quite interesting. I believe it could use MIDI connections or a 850 and the R: device to connect computers together to play each other. --Selgus

I second that - more info on this would be great. It was a cool game, but I really doubt the routine is the unable to be duplicated God's gift to code that some make it out to be. Not to hijack this thread, I will open up another about this technique. I am actually making a 2600 version of a prequel to ROF and wasn't going to talk too much about it until I could release a demo. Yes, the whole trick was being able to do the 3D rendering in a fast enough way on the 8-bit processor, using different tricks. The line clipper is how the near/epsilon/far plane clipping works in REYES and 16-bits because after perspective, you can have some large numbers that you need to get into screen-space range. --Selgus

Front to back, so if something was behind a currently rendered landscape, it was just skipped. --Selgus but what is the difference to a z-buffer then? The way the algorithm works is you have a fractal line that you draw into a Y-buffer (so heights for each screen column). Then when you have that line, you can draw it into a persistent frame buffer, and from the previous Y-buffer values, only draw the vertical line which is different from the last. For lines in the buffer that are behind your current Y-buffer, it skips. The depth information is not actually stored per se, the lines are just drawn front to back. Clipping was an issue, and how the fractals get generated via Gaussian random numbers, so you had to run the algorithm on the full line, culling sections, to get the repeatable fractal values for the Y-buffer. Maybe I should start a new thread about this... --Selgus

Front to back, so if something was behind a currently rendered landscape, it was just skipped. --Selgus