314 replies to this topic

[The Codex]

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.

[Opry99er]

Yea, ANDs are do-able... OR is also available, but I'm not sure to what capacity.

[Opry99er]

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 by Opry99er, Wed Mar 3, 2010 10:28 AM.

[unhuman]

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

Opry99er, on Wed Mar 3, 2010 9:25 AM, said:

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.

[The Codex]

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.

[Opry99er]

Boolean? What... Are we speaking Jabberwockian-ese now? Hehehe--- glad I could help.

[InfernalKeith]

That's my next 30-line program. FOOLISH EARTHLING... BEWARE THE WRATH... OF THE BOOLEAN COMPARATORS!!!!!!!!!!!

[marc.hull]

Opry99er, on Sun Feb 28, 2010 12:34 PM, said:

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....)

[Opry99er]

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

[The Codex]

Yep, looking at speech for my game too...

[marc.hull]

--> 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?)

[unhuman]

marc.hull, on Wed Mar 3, 2010 12:35 PM, said:

--> 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..

[Opry99er]

Yea--- as long as your game stands alone without assembly routines, you're fine. .

[Opry99er]

Unhuman, I have them-- I'll have to locate them... Probably by tonight-- unless Marc Hull would be so kind.....

[marc.hull]

Opry99er, on Wed Mar 3, 2010 12:48 PM, said:

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...

Attached Files

•  call loads.txt   6.18K   17 downloads

[retroclouds]

marc.hull, on Wed Mar 3, 2010 1:26 PM, said:

Opry99er, on Wed Mar 3, 2010 12:48 PM, said:

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.

[The Codex]

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.

[Tursi]

marc.hull, on Wed Mar 3, 2010 1:26 PM, said:

Opry99er, on Wed Mar 3, 2010 12:48 PM, said:

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.

[Opry99er]

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!

[Tursi]

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.

 zombxb.jpg   137.65K   9 downloads

Quote

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   1.87K   11 downloads

[sometimes99er]

Tursi, on Thu Mar 4, 2010 4:31 AM, said:

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

[retroclouds]

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

[The Codex]

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!

[Opry99er]

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.

[marc.hull]

--> 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