unhuman

Wow. If it's that easy to get you to do work, I'll humbly request that you make it write the game itself.

btw - if you could eventually get interrupt driven sprites to work, or provide some mechanism to sync to the refresh rate, that'd be awesome. Wouldn't want our games to behave all crazy depending on the amount of work done in the game loop....

Yeah, I'll echo that. I wouldn't have done this if I didn't notice the contest, and somehow my twisted mind got all excited. Not quite sure why, but clearly it was the right place / right time for me. I'm super excited now about TurboForth, for some reason, and I've never used that language. I don't know ASM very well, and learning it for the 9900 really is not in the cards. I should be doing c99, but for some reason, not really interested in that. And, of course, as a bonus, it gave my wife another thing to make fun of me for. I've been working on a game for the ColecoVision in C, but I've been away from that for a few years. A port would be fun, though, if I could make the original fun - and I was having issues with that, so, not sure that'll continue. And, one day, perhaps, I'll be lucky enough to catch up with Codex (coincidentally, he lives < 1 mile from me) for a few beers... How could that possibly be bad? -Howie

Tips from Howie - Inaccurate Invaders: 1. Move groups of objects in coordination by using characters in strings / DISPLAY AT. When a collision is detected (GCHAR), the location in the string is calculated rather than known. This allows consistent behavior to be managed with minimal code / performance hit. It was tricky to debug problems, however. But, I nailed them. 2. When moving things side to side using DISPLAY AT, if you put empty characters on both sides, you get erasing chars, without having to do that work yourself... 3. If you know there is a gap and collisions are missed - you could do GCHAR on 2 locations to minimize the misses (this was a late change I made) 4. Sometimes if things aren't responsive enough, you could do user interaction multiple times within your game loop. This may have a slight impact on other performance - but does give the perception of increased responsiveness. 5. If you are animating multiple objects simultaneously - use CALL CHAR. 6. When I explode objects, I just move a hidden sprite into view at the location of the explosion. At the end of the game loop, I just move the explosion to invisible location. 7. To build upon #6, sometimes it's just better to do something than to calculate whether or not you need to do it before you do it. IE - moving explosion to invisible location - no reason to check if need to move it, just move it. This also helps to keep the time the game loop takes consistent. 8. Understand the behavior of IF THEN ELSE. It has some funny behaviors that can be beneficial... 9. Leverage variables to do animation. For example, I keep track of variables that indicate state of var. For example, if a character flips between 2 states, I keep track of a variable that every loop does X=1-X, which gives a value of 1 and 0 alternating. Makes things easy and fast. And you can re-use that state for multiple things that have similar alternating states. 10. Don't forget RESTORE. I used this to restore and re-read the state of the invaders at the start of each level. This allows an easy reset within minimal work. There, 10 tips from 29 lines of code. Not a bad ratio, eh? A non-Inaccurate Invader tip: 1. When animating a magnified (4 char) sprite, you could just animate a single part of it by doing a call char. If you have multiple sprites of same characters - this is better than call pattern. I'm regretting not using my remaining line of code - think I could've made my title screen a lot nicer. Oh well. -Howie

Yeah, now that I'm heavily invested, it better come to fruition, else I'm suin!

Just found the book for < $5 shipped.... http://www.a1books.com/cgi-bin/mktSearch?act=showDesc&code=gbase&rel=1&ITEM_CODE=0138429227 -H

I think there's gonna be a contest for this one too! I'm sure Mark will look into it if there's a demand. Stand alone disk files will need a loader (and run) anyway (TI Basic won't do), and if you haven't got the TurboForth cartridge, it would still be nice to be able to load and run from EA or something similar. Stand alone cartridge creation will most certainly be a totally hot feature.

can't keep no secrets from Google: http://www.turboforth.net http://sourceforge.net/projects/turboforth/

#9!

We have any idea of the feature set? I should actually start looking at c99. I never did anything with that as a kid, but that seems the easiest way to go (for me). -H

Interesting - I remember a disk-based TI-Forth from when I was a kid... -H

Thanks for the super-fast fix!

Refixed. I prolly just didn't notice b/c I use keyboard. Thanks for the pointer.

y'know, coulda sworn I did it right - but whatever. I've openly lost my mind before. I also haven't played it on a real TI. But, there's a lot of competition, so need it to be as good as possible.

Or you could find the right place to call peek.... I'm sure that's just dreamin tho.

Not sure how that could've happened. Oh crap. Can't allow any more motions, etc. The game is already at it's limit for what it can do checking wise. It's packed tight. Wonder if I didn't do "new" between working stuff and just got lucky. Who knows.

Err - you guys serious? Guess there will a mad dash to recheck & fix before the deadline... Grumble.

Sounds like something is wrong with your TI.

1 CALL CLEAR::CALL MAGNIFY(3)::CALL CHAR(96,"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF") 2 CALL SPRITE(#28,96,2,1,128) 3 CALL SPRITE(#1, 96,2,17,11,0,7) 4 CALL COINC(ALL,A)::IF A <>0 THEN CALL SOUND(100,110,0) 5 GOTO 4 If you switch 1 & 17 to 2 & 18, no noise!!!! I'm not CrAzY Also happens in Call Magnify(1) when 1 & 9 but not 2 & 10 And, the sprite #s are irrelevant. They can be any #. This is all on Classic 99. Tried it on MESS and it's fine. Haven't tried it on real hardware. Guess I found a doozie

Thanks I'll try those tips!

I'm pretty sure it's not that... If I moved sprite #1 to location 256 (so it's 1 pixel up higher), it doesn't collide. I'll hopefully have time to do my sample tonight. Swamped with real work tho.

Please don't miss my update to Inaccurate Invaders. It's just less inaccurate now

Never heard of YLoad... but sounds like something that could be wrapped with a nice menu system & kept on dsk1 and load all the games off dsk2. Hmmm... -H Interesting. Do the games have to be patched with it to work or do you just put YLOAD onto the disk? My knowledge of how TI disk stuff works is very limited. Tempest

Remo - thanks for the educational stuffs. I need to see if I can get my kiddos playin this weekend.

Yeah, I'll create a sample. It was late and I was toast, but definitely 1 & 17 - which shouldn't be.