djmips

I'll try and come up with something.

So funny, I was reading my own post again today and it feels a little bit like Fermat's last theorem now. Even the 'now' me wants to know what awesome idea I had. I feel like I had a super idea but then got distracted and never got back to it and now it's gone into the ether...

I know you're a visual thinker and there are some diagrams at this link. I think the Pinball Dreams bitmap idea (mentioned previously) is a good one for an eight bit system aside from the memory required but since you are thinking DPC+ anyway, using cart space for the physics bitmaps seems like a good solution. https://gamedev.stackexchange.com/questions/43705/2d-collision-detection-for-pinball-game Note the link to the 6502 source code (For the C64) https://files.scene.org/view/resources/code/sources/pindreams64_src.zip Video of Pindreams 64 https://www.youtube.com/watch?v=NgcSN6e68jA

Ah yes, I suspected I would be corrected. Of course, the carry is the ninth bit. I am rusty.

This won't work because you could overflow if the numbers were both > 128

OK, I'll let the programmer know! Thanks.

Hey, thanks for that, I've forgotten how Stella works. I think it's confusing, the current UI. At least to me. What are the cfg files used for again? I have forgotten.

First of all, I checked and the very first versions of Apong in this thread use Paddle 0/1 (a paddle pair hooked to the Left controller port on actual hardware) It's only the very last version (posted in 2010) that use Paddle 2/3 (a paddle pair hooked to the Right controller port on actual hardware).

It uses paddles. A kernel that uses paddles has to make some sacrifices since the paddle must be checked frequently since it uses the time to charge a capacitor and that's sensed by a comparator. The timer is a soft timer (the line count in the kernel) that has to be stored when the paddle register goes minus. This pong kernel reads the left player one frame and the right player the next frame. So it alternates back and forth. That means the latency for paddle reading is 33ms for any particular player which isn't too bad under the circumstances. It would be possible to read both paddles in the same frame and improve the latency but that requires more clever code. A couple of things to note. I believe the posted version uses Paddle port 2/3. If you are using Stella you will need to do some config to set it up to use your mouse for the paddle. I forget the details but with some googling / playing with it you should be able to figure it out.

Nice! Is it just me or does the second player (bottom) have the controls backwards?

And now we have Rocket League!

OK, I'm getting it now, it's really more of a Street Fighter arcade stick style that this is suited for rather than something you hold in your hand. That's cool too! https://www.google.ca/search?q=street+fighter+arcade+stick&espv=2&biw=1331&bih=672&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMI-5Dz5MzexgIVQxiSCh0JdQUd

Yes, I'm interested. Looks cool. What are the dimensions of the PCB? I'm concerned about two things, that the PCB is too big in the smaller direction and that the analog stick might break from the board under heavy use.

Why not add a small microcontroller to the trackball like a 12C509 (8 pin PIC). It can feed you the track ball position serially once per frame when you ask for it and during the frame it can keep track of the track ball at a very high precision. The 12C509 should be a few dollars plus you might need the optional external crystal maybe.

Now Space Harrier for the 2600 would be astounding and probably impossible. But this game ballblazer looks to be on the cusp of where everything should roll downhill to completion. If you need an accomplice, let me know since I'm on a break right now and have a lot of time.

This is an amazing thread. Like most things, I missed this because I miss most things because of work focus. I'd like to ask, when did you come up with this technique (year) and when did you code up your polygon routines? I wrote some polygon fill routines for the Atari ST around they year 1991/1992 and I actually saw the technique in an HP Patent from about the mid nineties! Weird (it wasn't that an amazing idea - just using breaking down the polygons into trapezoids and using a dual dda trapezoid filler as the primitive for everything. In 68000 it came out pretty good, I kept everything in registers. I don't know how it compares to the really good polygon / 3D routine. I always thought that I never got to the ultimate speed for this (actually the rest of the 3D pipe had some problems that I could quite easily solve knowing what I know today) But about your stuff. It's really great that you saved it. I totally wish I had the presence of mind to archive my work and experiments... All I have is a box of 5 1/4" Apple II source code that I'm currently trying to restore.

Wow. A 3D open world game from way back when!

AGC - Apollo Guidance Computer!?

Ok wow, that had always confused me in the original game, knowing they auto-rotate makes the game more sensible to me now.

This version is pretty cool especially for less than 2K. Does it only have the one Rotofoil?

Hey Chris, did you see this? Pretty cool. http://meatfighter.com/nintendotetrisai/

The skeleton animating to 'life' is tremendous and gave me a little thrill to see. Great job on that one!

I like the simple version. Is there source for this one?

On 4th down you may choose to kick. Hold Joystick right to display your down and press FIRE to punt or kick a field goal. The field goal is automatic if kick it far enough.

It's not completely accurate to call it the even frames of a 480i signal because that might sound like it was displaying at half the vertical refresh rate when in fact it's displaying at full refresh rate. The odd frame is there it's just not pushed down to create interlace.