Has anyone tried it out? It seems Patrick Davidson's made the first (?) full assembly game for the CSE, unfortunately i don't have one to test it out.

Edit: Oh, and of course the source is included

I'm trying to put together a routine that will calculate the appropriate X/Y velocity to go towards an object. What i've got now is really buggy, i think the general algorithm/idea is ok though. My biggest hurdle so far has been handling negative numbers, as none of my routines for multiplication/division seem to like negative numbers. What i'm currently doing is really just adjusting the Y velocity and not bothering with the X velocity. The general equation is something like this:
(object Y - bullet Y)/(object X - bullet X)

The X/Y velocities have 5 bits which act as a decimal place, but this doesn't let me use it. I hacked in the ability to handle negative numbers in the division routine (essentially turning all negative numbers positive, then negating the result afterward), but my multiplication routine doesn't like negatives numbers either.

EDIT: Updated the download here with the latest version. The port is more or less complete, though i haven't added in linkplay yet (there's no more space in RAM to add it ).

__________________________________________

A couple days ago i decided that i finally wanted to play Robot War. I've been wanting to play it ever since i first heard of it nearly 6 years ago. The main issue wasn't the code (it's very well commented/organized and really easy to follow), it was the SIZE of the program. I've finally gotten the size down enough that it'll fit within the RAM of your calculator (as long as you have no other programs loaded, and you may need to delete L1-6), and thanks to Crabcake you no longer have to worry about RAM clears everytime code past $C000 tries to execute

There are still a couple bugs, notably there're some random tiles that get drawn to the screen during the battle engine, and i haven't tested very much. I'd really appreciate if you all could help me look for things that still aren't working, since the main part of the program has been fixed up to run under the 83+. Save files are also working, on the 83+ you'll only be able to fit one in right now (and i had to restructure the data quite a bit just to allow that). Because the 84+/SE version of Crabcake is slightly smaller, i can post an 84+/SE only version which should leave you another couple hundred bytes to play with.

This is just the Standard Edition (no linkplay), eventually it would be best to convert it into an app but i just wanted to throw together a quick playable version first.

Also, please note: i don't recommend putting this on your real calc, for a couple reasons. 1) it's largely untested and it's possible (very likely) that at some point it will crash. 2) you probably won't have enough memory (RAM) to fit it on there

And if anyone knew how to get in touch with DigiTan, i'd be very grateful as well.

Screenie:

I've been wondering how you can keep track of all the things you've done in a game, how you can advance while unlocking new places, opening treasure chests, NPCs coming and going, maps changing (for example, maybe a house gets built while you were out of town, or a rock gets moved). It's a lot of information to track and i don't think you want to make a second copy of every map in your game. Maybe my problem is that i have a lot of these things built into my maps when i need to somehow separate them?

I'm pretty sure in the normal running of the calculator, you rarely will have more than 50 bytes of data pushed onto the stack. Where exactly does the stack start? I always assumed it started (or rather, ended) at $F000, but that's like 4kb of stack space. Is there any reason you shouldn't touch this area if you know your program won't come close to touching it? And where exactly does the stack... end? I was just looking through the source to a program and i think it uses that area for variables/as a gbuf for its grayscale routines.

Currently what i do is just load a list of enemies when i go to load the map and run through and update the entire list each frame. Really it doesn't take so long and even with maybe 20 enemies the slow-down isn't that noticeable, but i think i will probably just build them into the map so that they are triggered when you reach a certain tile. I'm not sure how large the final levels will be. Anyway it wouldn't be too difficult to do, i've just been lazy and not really sure if there are better ways to do it.

I've also never done enemy routing/paths, will i need to touch any trig? Right now the enemies just kinda fly around and bounce off the walls, which i think is pretty interesting and a little funny even but maybe not so practical for the final game.

I guess it's not really anything i desperately need help with as most of the code's already written, but it'd be fun to talk about something here and hear your ideas (and not just ASM programmers, since i imagine the concept would be basically the same), i learned a lot from the old tilemap discussions over at RevSoft and MC.