The Codex Posted March 3, 2010 Share Posted March 3, 2010 Whoa, you can use AND in XB IFs? Can you also use OR? I must've overlooked this in the manual, because I'm quite used to doing things this way in other languages. That'll be great if XB supports it as well. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2010 Author Share Posted March 3, 2010 Yea, ANDs are do-able... OR is also available, but I'm not sure to what capacity. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2010 Author Share Posted March 3, 2010 (edited) Try this code.... It will print "success". THen change line 10 to say "A=1" and leave the rest of the line the same. You'll see. =) 5 CALL CLEAR 10 A=2 :: B=1 :: X=3 :: Y=4 :: P=1 40 IF A>B AND X<Y AND P=1 THEN GOTO 300 ELSE GOTO 200 200 PRINT "OOPS" 205 GOTO 205 300 PRINT "SUCCESS" 305 GOTO 305 "OR" works the same way. You can use the hell out of em. Should bring your code size down if you were using multiple lines to determine this. Edited March 3, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
unhuman Posted March 3, 2010 Share Posted March 3, 2010 I'm trying to avoid all sorts of branches... Just wondering about the oddities. Just wanted confirmation that the system was crazy and not me. -H 40 IF A>B AND X<Y AND P=1 THEN GOSUB 300 ELSE GOSUB 200 This checks for 3 conditions and if ALL are true, it jumps to 300. If ANY of these are UNTRUE it will jump to 200. Of course, this looks bulky... But it works. Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 3, 2010 Share Posted March 3, 2010 ANDs and ORs will certainly reduce the number if nasty nested IFs in my code. Don't know why I got it into my head they weren't supported in XB, probably because they weren't exactly highlighted in the IF-THEN demos in the manual. Boolean comparators should be loudly proclaimed when they are available. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2010 Author Share Posted March 3, 2010 Boolean? What... Are we speaking Jabberwockian-ese now? Hehehe--- glad I could help. Quote Link to comment Share on other sites More sharing options...
InfernalKeith Posted March 3, 2010 Share Posted March 3, 2010 That's my next 30-line program. FOOLISH EARTHLING... BEWARE THE WRATH... OF THE BOOLEAN COMPARATORS!!!!!!!!!!! Quote Link to comment Share on other sites More sharing options...
marc.hull Posted March 3, 2010 Share Posted March 3, 2010 Thanks to Filip and a few others, the Atariage TI-99 forum is a bustling hub of activity. My personal thanks to Filip for starting the first contest, and this post is to announce a brand new game program competition. Here's the deal:: this is the (S)hort and (S)weet (G)aming ©ontest A 30 line BASIC or XB game on the subject matter of your choice. 30 lines of program and an additional 10 lines available for DATA statements are available. The format for this is designed to make the competition do-able for everyone. You may not have time to do a 300 line game or one done in assembly, but a 30 line game will encourage creativity. . Competition starts immediately and will end on April 15th. Good luck! First prize--- a CF7+ with a 512 MB card, a TI99/4a console, and an XB cart Other prizes (2nd and 3rd place) will be announced later. Found another horse to beat here. What can the system comprise of that the game runs on (Speech synth, Mem-Ex etc....) Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2010 Author Share Posted March 3, 2010 32k yes Speech synth yes basically if it'll run on a basic system, then yea. No SAMS (although I don't think you need it), just a stock TI, speech synth, standard PEB... You know.. . Speech would be cool!!! No assembly access (CALL LOAD, CALL LINK) though--- just straight XB. Have fun Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 3, 2010 Share Posted March 3, 2010 Yep, looking at speech for my game too... Quote Link to comment Share on other sites More sharing options...
marc.hull Posted March 3, 2010 Share Posted March 3, 2010 --> No assembly access (CALL LOAD, CALL LINK) though--- just straight XB. <-- What if you use CALL LOAD "JUST" to fiddle with the memory locations only (as in PEEK or POKE)with no machine execution ? (Getting exasperated yet?) Quote Link to comment Share on other sites More sharing options...
unhuman Posted March 3, 2010 Share Posted March 3, 2010 --> No assembly access (CALL LOAD, CALL LINK) though--- just straight XB. <-- What if you use CALL LOAD "JUST" to fiddle with the memory locations only (as in PEEK or POKE)with no machine execution ? (Getting exasperated yet?) Yep, that's what I want to do... Where are all the locations documented? That's what I want.. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2010 Author Share Posted March 3, 2010 Yea--- as long as your game stands alone without assembly routines, you're fine. . Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2010 Author Share Posted March 3, 2010 Unhuman, I have them-- I'll have to locate them... Probably by tonight-- unless Marc Hull would be so kind..... Quote Link to comment Share on other sites More sharing options...
marc.hull Posted March 3, 2010 Share Posted March 3, 2010 Unhuman, I have them-- I'll have to locate them... Probably by tonight-- unless Marc Hull would be so kind..... Bob Carmany just posted them on the no drama TI site so that is where I got them. Here they are hopefully... call loads.txt Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 3, 2010 Share Posted March 3, 2010 Unhuman, I have them-- I'll have to locate them... Probably by tonight-- unless Marc Hull would be so kind..... Bob Carmany just posted them on the no drama TI site so that is where I got them. Here they are hopefully... Perhaps we should add those to an "Extended Basic" tips&tricks page. I'll see if I can add it to the development resources thread. I've been collecting some things to add but didn't find much time to update the thread lately. Will try this weekend. Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 4, 2010 Share Posted March 4, 2010 My first entry is up - Fly Guy. May be tweaked a little as I regain the ability to write XB, but the game will stay largely the same, for better or worse. Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 4, 2010 Share Posted March 4, 2010 Unhuman, I have them-- I'll have to locate them... Probably by tonight-- unless Marc Hull would be so kind..... Bob Carmany just posted them on the no drama TI site so that is where I got them. Here they are hopefully... ... there seem to be some errors in that list, or at least poor choice of terminology (for instance, you can't CALL LOAD the sprite coincidence register to any value, it's read-only and the RAM location is just a mirror you can CALL PEEK). I can't sit and try them all, but if you find some that you want to use that don't work, don't be too shocked. Feel free to ask if there's another way for specific ones that don't work. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 4, 2010 Author Share Posted March 4, 2010 Yea--- I looked over that list earlier and you can peek into the VDP status register all you want to--- but not LOAD it... Weird. I used a CALL PEEK to the byte containing the coincidence indicator in the VDP status register during the Honeycomb Rapture development, but it proved to be no faster or more precise that CALL COINC(ALL)--- I imagine that the GPL interpretation of CALL COINC(ALL) is simply a peek to that byte--- probably wasn't any more efficient because of my gameloop structure... There is a test for that--- but if I understand your predicament correctly, you aren't using SPRITEs anyway--- this might be a moot point. Tursi's the one to ask about this stuff for sure! Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 4, 2010 Share Posted March 4, 2010 Actually, CALL COINC seems to go and hit the VDP again.. I thought you'd said the CALL PEEK was faster. Ah well.. will benchmark it another time. I got inspired and stayed up far too late doing a quickie. I consider this more of a warm up, it's the first XB program I've written in years, but I don't know that I'll get to anything else for the contest. Trapped in a blue world, surrounded by zombies, with only your innate laser powers to survive!They want to eat your brains, so stay one step ahead of them! Use the joystick to move. You will automatically fire in the direction you are moving. The zombies are coming up everywhere, and moving in towards you. They're slow, but deadly, and only a head-shot will take them out. Some of these guys are JUST floating heads, take those out too! Don't worry about a headless body - eventually it will disintegrate. It's harmless! You score one point for every step you take and survive. You get two points every time a zombie spawns, so keep blasting! Watch out for the electrified barriers - if you touch one, that's instant death! ZomBXB (Zom-B-X-B ) is a simple little shooter, loosely inspired by Robotron and that zombie farmer concept in the other thread. Originally I coded it for two joysticks, but that was way too easy since it can't speed up enough to overwhelm you, so it always fires in the direction you are moving. Might be a couple of little bugs still, but I've played it a fair bit tonight. 30 lines of code, 3 lines of data.. though there's lots of room left technically, quite a few lines could still be packed. Still.. even though it's a bit easy, hopefully there's a little fun to be had. On the technical side - I really cheat with the laser. Even though I'm using sprites for the players and zombies, the zombie heads are background characters. So I just draw and erase the lasers... zombies quit moving if they lose their heads, and eventually their body is recycled. That helps keep the framerate up (and explains the odd scoring - by giving you points when a zombie spawns, you are still encouraged to shoot them, without having to check every position erased.) If they get too close to you, you can't shoot them, you have to back off. This is because you move before you shoot, but I left it that way to ensure there is a bit of a challenge - if they get close you need to make sure you still have an escape route! Unzip the files, and drop in the Classic99 DSK1 folder. It's intended to run at normal speed, but it will run okay in CPU OverDrive (though be a bit harder ). ZombXB.zip Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 4, 2010 Share Posted March 4, 2010 Unzip the files, and drop in the Classic99 DSK1 folder. It's intended to run at normal speed, but it will run okay in CPU OverDrive (though be a bit harder ). I get * FOR-NEXT NESTING IN 1010 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 4, 2010 Share Posted March 4, 2010 Will try this evening. Looks cool Looking at the screenshot the game has an Odyssey 2 touch. The Odyssey 2 (known as Philips Videopac G7000 in Europe) was my very first game console before I even had a TI-99/4A. Ah the memories Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 4, 2010 Share Posted March 4, 2010 Nice one Tursi, I'll check it out later. Cool that it runs in normal speed, too. I noticed that with CPU Overdrive on, speech runs too fast to be comprehensible, so I left it out of my game. Does anyone else experience that? Oh, and while I'm on the subject of the excellent Classic99 (such a great development tool too), is there any way to perhaps add a menu choice that resizes the window to exact magnifications? I like to run everything in unfiltered pixel mode at 2x or 3x size, and it would be fantastic if the window sized itself to match those proportions. I always seem to get it a little off when I resize it by hand. Not a huge necessity, it's a fab emulator in any case, just thought I'd ask in case it's simple to implement. Meanwhile, hoping to see more contest entries! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 4, 2010 Author Share Posted March 4, 2010 I'll certainly be playing this one this afternoon!!!! . Thanks for the entry! Listen, if we have at least 15 entries, I'm planning on putting all these games on a disk to be released at the Faire.. Calling it the "Disk 30" disk. (thanks Codex)--- that is, if you all would allow it. If you don't want your game on the disk, shoot me an email and let me know. Quote Link to comment Share on other sites More sharing options...
marc.hull Posted March 4, 2010 Share Posted March 4, 2010 --> Actually, CALL COINC seems to go and hit the VDP again.... I am not sure this is correct as I ran into an interesting situation yesterday using the COINC sub. Apparently XB can outrun the VDP interrupt when two CALL COINC's are run back to back. I had an odd error that had no other explanation. When I spaced the calls out time wise a bit(no pun intended) the error corrected itself. If the COINC sub was reading the VDP status reg then this could not happen as that register is cleared after a read. I believe that the sub is used with the "ALL" parameter it is looking at the scratch pad location (can't remember which one) and reporting back on it's status. Amazing to think that XB can outrun anything Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.