Retrospect

Am I right in thinking, I could benefit from this too? The way my games (Eric in Monsterland) and the new RXB Castle Conquer work, they gosub routines for character patterns (one for main game, one for the title screen), and they also have gosub routines to place trees, houses, walls, fences, etc etc, so my subprogram to build a single screen would be like 1100 GOSUB 9110 (call screen 2 and all colors black) 1102 GOSUB 9200 (places the ground) 1105 R=18 :: C=20 :: GOSUB 9210 (places a tree) 1110 GOSUB 9120 (call screen 5 and appoint all necessary colors) I'm thinking all my gosub routines could occupy the 2nd bank of 24K leaving my main program 24K bank 1 ?? Would that work or would character patterns have to be defined in both banks?

Thankyou Am1933 There's just a bit of difficulty to increase on certain screens just yet. Ciro managed to get past the 2nd to last screen and I still haven't gotten past that yet haha

With just ONE statement line, I was able to put the "pits" into the wall. That's good.

ok, so the extended basic that is built into the ti-99/8 ... that differs from machine to machine?

Are there any plans to include 99/8 emulation into either Classic99 or JS99er? Some of that 62.5K memory could be very useful along with the 12MHz speed. Of course, the 1st thing I would do is make a conversion of my Castle Conquer game for it.

Castle Conquer is being made for Rich Extended Basic. The finished game will have collectable items such as treasure or extra lives. RXB's CALL COINC command makes it much much easier to differentiate sprite collisions and we can easily determine an enemy to a collectable object in just one statement. I've not done so much so far as I'm still wrestling with the Eric In Monsterland project at the moment.

Revision 5 MONSTER5.zip

cheers sometimes. Another update will be along before too long.

Hi Fabrice. I noted that the walking noise was a little loud, I've kept it in but made it quieter. As for music, that'll be included as soon as I can get my head around how to do it. And even that could become repetitive itself.

Revision 4 , game download here, and at top of thread. Gameplay video Game MONSTER4.zip

ok , thanks lee

MONSTER3.zip Here's revision 3. Eric now makes a sound whilst walking, and when he dies a brief death tune plays. There's a short delay still to be put in after he dies but nothing major there. Eric now appears properly on the final screen (dragon 'n' chasm) Does anyone know if there's a CALL PEEK i can do to somehow get a variable from a clock timer at all? and if so is there a way to re-set it at each screen? Just thinking of a time-based score without having to use a black sprite that goes from left to right (cos that adds more bytes and will slow it all down too much!)

You're welcome, Fabrice. I've noticed a bug on the final screen. I'll put up a new revision soon, Eric appears at the bottom instead of the top, making it impossible to catch the flying dragon.

Thanks for trying it guys. Here's beta rev.2 Updates: Player now re-spawns at start of every screen Lives are shown at the top of the screen Next update: Music / Effects. MONSTER2.zip

Thanks Ciro Yep - movements on the stick are generally not nice unless 3rd party sticks involved. Eric can do: walk back / forwards <left/right> Jump back/forwards <up left / upright> Jump straight up <up> Crouch / duck <down> Note that on the dragon and chasm screen (yes there's a castle again!) you only have 1 chance per life to jump at the dragon, missing dragon means you slip and fall!

Eric in monsterland , EA5 and Fiad files here Monsterland.zip Monsterland EA5.zip Needs 32K and Extended Basic or Editor Assembler

If you give some examples of your code, I'm sure someone will point out things that can be done using less bytes.

If i can get my hands on an Xbox360 wired controller and a modern-ish windows machine I will test my theory of XB being able to address MORE than just 4, and -4. Only reason no one tested it on real iron ever is 'cos TI didn't supply the analog hardware (Idiots)

I've been having "memory full in 10" when I've got 2.5 to 3k left in program space and around 4.3k of stack. It's a real nightmare.

I know what you're saying, they're a pain aren't they. But that's my point, the commands should be addressing analogue values not just on or off, and the only reason i can think they made the joyst command so complex IS for analog. If only that could be addressed through XB ... it sure doesn't look like it was removed - it looks like you can address 0-7 instead of sticking to -4 or 4 ... but we've no analogue sticks to try it with. Unless anyone has an xbox360 controller with mess / mame in windows!

that's looking great. I like the multi-coloured player character

hey this is looking good

Shame XB can't address it with CALL JOYST(1,JX,JY) IF JY=2 THEN SPEED=2 IF JY=3 THEN SPEED=3 and so on ... instead of the usual 4 or -4 , could have / would have been interesting.

Hello everyone. Just thinking about the joysticks and the 8-way directional commands that come with them ... Extended Basic would be limited to 0,-4 and 4? Why are the numbers done so, almost as though they (TI) were going for analog control by perhaps 8 values or more for each direction ? Has anyone in assembly (I can't do assembly) tried tinkering with the velocities, are they addressed in the same way? I did hear something about analog sticks being considered for the 99/4 (Dimension-4 prototype had it, iirc ) Would have been awesome for parsec - no need for keyboard 1,2,3 shift? Pictured are a set of wired controllers for the 99/4 and possibly Dimension-4. If you look, there's enough "give" in the space between the stick and the outer hole for an analog push.

Ha! I thought that spider looked familiar! Gets everywhere that bloody thing. A trick I do with that spider, is have 3 different sprites, 2 with legs moving in different ways, the third the same, but shift the sprite down or up by 1 pixel to simulate the spider bobbing up and down..... the 64-character codes are copied from sometimes99er's patterns program (thanks karsten!) to chars 112,116,120 and a little variable, called W, is set to 112 on introduction to the sprites on the screen. Then whenever the player does anything (and inbetween waiting for the joystick action) the spider animated with W incrementing by 4 every time, kind of like this; 1100 W=W+4 :: IF W>120 THEN 1101 ELSE 1110 1101 W=112 1110 CALL SPRITE(#1,BABY,16,BX,BY,#2,W,13,100,-16) :: RETURN This subprogram would keep track of the baby's whereabouts and the spider just animates whilst in automotion .. for other screen it's mapped to an array called A1(xx). But you get the gist of the machination involved with it. Great fun. Looking forward to seeing your game in action.