Inexpensive collision detection for the 80-column screen

[nikoniko]

I suppose this is one of those completely obvious "duh" kind of things, but it never occured to me until I started on the game compo.

So, here I was, I'd put together some software sprite code for the 80-column screen, and I was thinking to myself, Boy, I sure do miss hardware collision detection. Then all of a sudden it dawned on me, Hey, why can't I use the VIC's collision detection? The VIC is still mine as long as I use 1Mhz mode*.

The VIC doesn't have the horizontal resolution of the VDC, but for my purpose it's perfectly suitable, and I prefer the elegance of interrupt-based collision reporting rather than having my code checking collision on every movement. Even the 1Mhz mode* thing doesn't have to be a limitation if the extra power of 2Mhz is required, since one can switch to 1Mhz before updating sprite positions, then switch back. Sure, the extra setup and movement of VIC sprites takes some space, space which could just as well be used for my own collision routine, but the ease of implementation makes it worthwhile to me. Besides, it's just fun to use the VIC and VDC together, employing their different strengths in a complementary fashion.

By Aprill 1st this strategy may end up being thrown out in favor of another, but for now it tickles me pink to have both display chips doing something useful.

*Re: 1Mhz mode. Actually, with the 2Mhz VICE hack, sprites still work in 2Mhz mode. As far as I'm aware, however, this should not be the case on a real machine since the VIC would be processing garbage data whenever 2Mhz mode is selected.

[hydrophilic]

That's pretty creative!  So it's basically like duel processing, doing sprite movemnts on VIC to match software sprites on VDC?

I tend to agree (but cannot confirm) this would fail at 2MHz on a real C128.  I think the real thing would actually stop the CPU and accurately fetch the sprite data, (like in normal 1MHz mode) but it would fetch _random_ data because the sprite pointers are fetched from RAM without stopping the CPU (hence VIC would get pointer for whatever the CPU happened to be looking at).

Sounds like a neat experiment for C128 owner.

[nikoniko]

So it's basically like duel processing, doing sprite movemnts on VIC to match software sprites on VDC?

Yep. It has its drawbacks, but I just had to do it once I thought of it. I'll never take any awards for good assembly programming -- I've been away from low-level code for too long -- but if someone throws up a category for "most unusual approach" I'll win it every time.

I'd love to do more with the dual capabilities of the VIC/VDC combo, some sort of dual screen app or game, but that'll have to wait for another time. One idea I have, which would be much more practical with VICE than a real machine, is a Nintendo DS-like control system, with mouse or joystick interacting with the 40-column screen and the 80-column display corresponding to the upper screen of the DS. Or vice versa. Another idea is a game for two players at once, with each player controlling their own full screen. Now that would be fun to try on a real machine!

[Guest]

I've actually seen a couple of programs (many moons ago) that gave you data in both displays if you have two monitors.  You can send data to either display at any time in 1mhz mode.  I did actually see an article (again, can't remember where, possibly LoadStar) that advocated a Text adventure that use the VIC for displaying a map while the player did all his text based stuff in 80-columns on the VDC.  If you didn't have dual monitors you would still be able to play the game, just without always seeing the map, though you could always switch the display mode of the monitor to peek at the map.

[nikoniko]

The text adventure thing sounds like a really good use for that. Something which doesn't require the second monitor, but if one is available enhances the experience.

I wonder if any BBS software ever did that? One screen displays what the BBS is showing the current user, while the other is used for information and/or administration.

[Guest]

Since BBS programs are very very CPU intensive, I would imagine that the performance hit of running at 1mhz so the VIC would be visible would eliminate the benefits.

[nikoniko]

True. One would lose one of the key advantages of the 128 over the 64 for running BBS software.

[adric22]

Wow, I had thought many times about writing a game which used both displays.  My thought was always something along the lines of Ultima series.  Only that the VIC would be used for a nearly full-screen map where your characters walk, etc.. And the VDC would be used for all that other stuff like comands, inventory, character stats, etc.   Actually, back in the day, I was so obsessed with the VDC and "prooving its worth" to people, I would have likely made the important parts on the VDC.  What I didn't realize at the time, however, is how few people actually even had an 80-column monitor.