unhuman

Holy crap. I never expected a response like that. You almost made me cry. Thank you. Last time I programmed a game for the TI was probably 1989-ish. The time per line was quite high for me. I still like Cyber-Run. -Howie (not be be confused with Howard/Codex - altho he's a jeeeeniooous)

Not sure why..

Great game that I suck at. Can't imagine how horrible it'd be with real TI sticks Anyhow, minor bug spotted. After your game is over, your score gets cleared, so you can't see what you got unless you ditched the high score. -H

Pretty damn addictive. The inertia is amazing! And, it hides the slowness of the console very well!

grumble. Nice font.

Inaccurate Invaders is up. Saved a line of code and added a lot of stuff - more colors, etc... Wonder if there should be a reward for the most characters used in a game - per line average. Some lines are hard to get out of being short IF / THEN confusion, but... I think I packed 'em pretty tight

Inaccurate Invaders 29 Lines / 7 DATA InaccurateInvaders.zip Updated 4/13/2010 : Now less inaccurate. Improved collision detection

Or can he give his spares to me. My title screen is... Boring. Question for the judges (or, well, Owen).\ I am nearly finished with a game and I have a couple lines left over. I'd like for the game to save and load high scores to disk. Is that kosher, since it's not loading numeric or string data to get around the 30-line requirement?

My game is done. It's exactly 30 lines + data. Not releasing yet - I have a bug. -H

There has to be some trick to success in this game. I threw away tons of quarters, but never got anywhere. Still can't.

I see Simon!

My game is getting close. Made a few sacrifices, but... Overall, I think it's gonna work out. I wonder what the average hours / line spent. Oh - and I'd like a little help. My ability to generate sounds sucks... Anyone got a "shooting missile" sound? One call sound pls -H

At this pace you'll have 857 submissions and I just hope to finish my 1

So are you telling me that all the games I played 30 years ago could've sucked less? Also, since you talk about CALL COINC reading at the end of the frame, does that mean using it will slow down my game unless I get lucky that it runs near the end of a frame? That stinks. That's my problem, that doesn't explain it. That theory has potential for your case, but makes no sense in mine. Look at the example program that I'm working with, not your example. My sprites are not moving. They are always touching. So the COINC should never return 'no coincidence'. But it does, and so does the CALL PEEK. If the ISR is the only thing writing that memory location, as my debugger tests suggest, then yes, the ISR /is/ missing coincidences. This is observation and not supposition. Let's start with the simpler of the two cases. I should have paid more attention to what you wrote ;-/... I tested your code on my console and saw the results first hand. Your code on my console resulted in about 50 percent missed hits. That seems disheartening for XB programming. Now the strange gets stranger...... I got sick of trying to keep track of the scrolling ones and zeros so I changed the print format to..STR$(ABS©); in order to just see the 1's and 0's. This resulted in a reduction of misses to about 1.4 percent. On a whim I turned off all sprite motion with CALL LOAD(-31806,64) and got zero missed COINC's (out of 1000 tries.) This is beyond my scope so I will defer to your expertness in things of this nature but I would suspect that something other than the ISR is reading the VDP ROR or the scratch pad location is getting changed by some lurking XB/console bug. Perhaps a call to the TI software engineers is in order

I do all my dev in a text editor and paste the code into classic99... my code looks like this REM my code initializes better than your code 10 initialize REM my code plays better than yours 20 run game REM my graphics look better than yours 40 DATA my, graphics, rock By putting comments as REM lines they can be pasted, but do not wind up as code. Sneaky, eh?

Why do you recommend gosubs? That is extra stack manipulation and steals clock cycles. Right now, I've got my entire game loop with no externalized operations. Just a tight loop. What would be a really good thing to have at some point is documentation on how long each operation takes... But, I'm sure nobody has time for that. I've got a few more things to put into my game loop - I'm going for all the marbles in my game, else I'll fall back to my "less good" strategy. I'm pretty amazed at how many moving objects (w/o sprites) one can have -H

My game is so damn good it's writing itself, so I have more time to stay on here and tell you all how much your games suck.

TUPPINS!

I'm actually pretty surprised the amount of work I'm doing and how responsive the system has been. Of course, I'm probably fully loaded and as soon as I add more game elements, I'm probably screwed.

Save it for the smack talk!

Can we just get a sticky post with entries?

My game is better than your game. I hope. 10 lines of code, 3 lines of data and it's playable. It ain't done by any means! Oh, and Yo Mama!

Damn zomb is awesome... One minor issue is that sometimes zombies appear right on top of your head, so you get no chance to live. Should be a minimum distance safety zone The bar is set high!

Ok - now I'm gonna feel stupid. I've been using Classic 99 to run, since it supports cut and paste so nicely, etc... but... I cannot get it to use any of the files on disk... Copied the ZOMBXB to the DSK1 dir and doesn't work "OLD DSK1.ZOMBXB" - error 7. Disk menu is disabled... I'm not so dumb. I had to pilfer the classic99.ini file from Tursi's site forum to fix this... No disk driver.

My program uses auto-motion right now... I should try seeing if locate would work better for me... It certainly would give me the accuracy I'm looking for.... So long as I can keep the time in my loop pretty normalized... It'll be okay. But... That might be hard to do.