Jump to content
IGNORED

Bouncing Babies


jchase1970

Recommended Posts

7-6-2010 Small update to the game made, new file posted, a smoother baby pattern. Looks a little better when watching it. I think I can say it's done now.

 

 

The original,

http://www.youtube.com/watch?v=5CdB8y3GHvs

 

The remake,

http://www.youtube.com/watch?v=HabH_ilipvk

 

The final,

http://www.youtube.com/watch?v=MRL-N8csBBw

 

 

 

A old game I had on the pc. I found it a couple of days ago on a dos game site by accident. This game was written in ti-basic and then compiled with Harry Wilhem's Basic Compiler. You can speed the game up on the title screen by pressing 1,2,3. It defaults to speed 2 and resets to 2 after each game.

 

Differences in the versions, the TI version operates the same way as the PC version, graphics had to be compressed from 320x200 to 256x192, oddly enough the babies are a pixel bigger. Speed is had to judge, on the DOS box I played on my TI version runs faster, on the YouTube video of someone else playing the PC version runs faster, to fix this I added a option to adjust the speed of the game. I love HI-SCORES tallies, and so I added one to this game, I really think all scoring games need a HI-SCORE tally to shoot for when playing.

 

The file was then made to be xb-autoloaded. Made using c99 emulator. Hope it works for everyone, for some reason I can't get it to play in Win994a emulator. I recompiled it in in Win994a but I have lost my Funnelweb disk in my recent crash so I can't assemble it. Any ideas why it won't play in win994a? All my other games, which have all been pure basic, load just fine when copied to a win994a tidisk file. I have used HWBC on win994a with no problem.

 

If anyone can send me a tidisk of Funnelweb that would be nice. I DL'd a copy on 2 dsks copied them to 1 dsk but it wont assemble, it kicks it out, can't find assembler i think.

 

xb autoload file, this file wont work on real TI machine.

BBABY.zip

 

ea5 files **this file DOES work on a real TI machine**

run file BABY5

BABY5.zip

 

grom file

BOUNCING.bin

Edited by jchase1970
Link to comment
Share on other sites

Looking at the Youtube Vid's you get very close to the original. Definitely have to try it out this evening :D

 

Mind sharing some more details on how the development was done ? How did you convert the graphics ?

 

So the game was written in pure TI Basic and then compiled with Harry Wilhem's Basic Compiler ?

If it is written in TI Basic it means no sprites were used at all, I'm pretty impressed with the results.

 

I don't know this compiler, is it publicly available ?

Perhaps we can get the authorisation for adding it to the Development Resources thread.

 

Very nice! :thumbsup: :thumbsup: :thumbsup:

Link to comment
Share on other sites

Looking at the Youtube Vid's you get very close to the original. Definitely have to try it out this evening :D

 

Mind sharing some more details on how the development was done ? How did you convert the graphics ?

 

So the game was written in pure TI Basic and then compiled with Harry Wilhem's Basic Compiler ?

If it is written in TI Basic it means no sprites were used at all, I'm pretty impressed with the results.

 

I don't know this compiler, is it publicly available ?

Perhaps we can get the authorisation for adding it to the Development Resources thread.

 

Very nice! :thumbsup: :thumbsup: :thumbsup:

 

 

The compiler is old school stuff you can download it from Tigameshelf. It doesn't support sprites, it based on straight TI basic with a couple of extra features like large char values in XB, multiple statement line like XB, compound color statement like XB. But I didn't use these features as I wrote this in TI-Basic so I could test it as I developed it.

 

So as you know TI-Basic has no sprites to all the graphics are done with HCHAR or VCHAR statement. I made a few gosub routines for drawing and erasing chunks of the screen,

10000 rem draw blank 4x4
10005 rem pass x,y
10010 call hchar(y,x,32,2)
10020 call hchar(y+1,x,32,2)
10030 return

10100 rem draw baby
10105 pass x,y,b
10110 call hchar(y,x,b)
10120 call hchar(y+1,x,b+1)
10130 call hchar(y,x+1,b+2)
10140 call hchar(y+1,x+1,b+3)
10150 return

 

so here are 2 examples, before I gosub these I set variables x,y to the location and b is the one of the 4 baby values. so,

REM ERASE BABY from old position
240 X=asc(seg$(xp$,BABY(I),1))
241 y=asc(seg$(yp$,BABY(I),1))
242 GOSUB 10010

and

REM DRAW BABY IN NEW SPOT
310 X=asc(seg$(xp$,BABY(I),1))
320 y=asc(seg$(yp$,BABY(I),1))
330 B=108+(asc(seg$(Bp$,BABY(I),1))*4)
331 GOSUB 10100

 

The baby locations and the baby picture value(1-4) are stored in strings that are 31 characters long since there are 30 spots to locate the baby and 1 character to tell it that the baby made it to the ambulance. There is a launch sequence string and before a baby is launched 2 items have to be true a random value greater then 50% and a launch bit from the launch string=1. The launch sequence makes sure that never are there 2 babies in need of a fireman bounce at the same time. So the game can be played perfectly but it never ends. Matter of fact the self play on the title screen does play the game and he never misses, he scores pts and increases the waves but he doesn't get to set HIGH scores.

 

Since basic has no DISPLAY AT command like XB all the text and numbers are drawn in a routine like the babys,

10200 REM WRITE STRING
10205 REM pass x,y,text$
10210 FOR SL=1 TO LEN(TEXT$)
10220 CALL HCHAR(Y,X+SL-1,ASC(SEG$(TEXT$,SL,1)))
10230 NEXT SL
10240 RETURN

Just set x,y locations and the text$ string then gosub to it.

 

 

 

 

Using the compiler is easy.

1 make the program.

2 save the program with XB MERGE command,

3 run the compiler, with this program with c99 on fast speed it takes about 90 secs to compile. This creates the SOURCE file

4 load up an assembler and assemble it and create the OBJECT file.

5 run Harry's CLOADER program that makes the XB autoload program.

6 save the final program.

Edited by jchase1970
  • Like 1
Link to comment
Share on other sites

Looking at the Youtube Vid's you get very close to the original.

 

It's an action game so the game play was key. It has to have the same game play as the original. Then the graphic look can be made in any style. I could have made the graphics simple 4 color graphics like the PC version but I believe in adding your own artist style to any program you remake. I don't want to just clone a game. Same applies to adding extras that "don't take away for the original game play." The HI-SCORE in this example, I think it adds my touch to the game but doesn't detract from the game play in any way.

Link to comment
Share on other sites

Okay, found my notes. Based on a series of "Game & Watch" for the GameBoy. I had been converting like maybe 20 percent of the graphics for a TI version. I'll concentrate my ressources on another "Game & Watch". Below is a video (x2) off GameBoy with TI palette.

 

fire.gif

 

:)

 

 

wow, that looks good, I was happy with the way mine looked until I saw this. But I maxed out my 16 character sets since this is written in basic. Matter of fact I have 2 character sets, I have to load a alphabet set for the info screen. Luckily you can update character sets in a flash, but still limited to only having 128 character on the screen at a time. The 4 babies take up 16, the firemen are 16 more. The Bouncing Babies title is 17, I could write over that for the game play screen and have 2 character sets available. There are also 2 sets of letters on the title screen, so that would be 4 sets.

 

Dang I don't know now. I was making a 80's pc remake and never saw this gameboy design before. If I revisit it it will have to be after the game I'm working on now which should be done next week sometime.

Link to comment
Share on other sites

wow, that looks good, I was happy with the way mine looked until I saw this.

Please don't be unhappy or anything, it was not my intention, your version is brilliant, good graphics, good implementation, good speed, good playability and certainly original in many ways. You did a fine job. I tell you I was completely amazed. Be proud and let's see more stuff from you.

 

The graphics I've shown earlier are 1997 Nintendo.

 

This is the 1980 model

 

game_watch_fire_silver.jpg

 

and a 1981 update

 

Game_watch_fire_widescreen.jpg

 

:thumbsup:

Edited by sometimes99er
Link to comment
Share on other sites

Just played this game.... dude, if TI BASIC can do this (compiled of course) then I feel like a wank with the stuff I've put out in XB!!!! You're gifted, man... thank you so much for contributing your skills to these type of games... and as sometimes99er said, can't wait to see more from ya!!! If you keep this up, I'll have to create a jchase dedicated page on the ol' website. =) Great work, my friend. Great work!!

Link to comment
Share on other sites

I made a small update, it doesn't affect game play. I added a full tile high roadway under the firemen. This let me raise up the firemen and some baby positions. Now they flow much more evenly when falling and bouncing. It looks better but might not be noticeable to some.

 

Anyway, lets call this one done. Hope you all have fun with it. I know I have fun with it :)

Link to comment
Share on other sites

How easy is it to make a cartridge? I compiled a copy of Bouncing Babies to ea5 format. I downloaded Tursi's MakeCart and made a grom file with it. It plays in c99 no problem. I made a cart image that plays fine in win99.

 

So what's next, is it simply burning an eprom and plugging it into a 64k board?

Link to comment
Share on other sites

GROMs are sadly not compatible with EPROMs. There's no /easy/ way to make them yet.

 

I have my GROM simulator working - it runs on an Atmel microcontroller and gives you a single-chip GROM replacement, though the pinout unfortunately could not be made compatible. But it's not quite ready to release, I need to add a little more code to allow larger versions of the Atmel to support multiple GROM bases.

Link to comment
Share on other sites

Tursi can you explain a bit about GROMs and EPROMs why they arnt treated the same in a cartridge? I've heard the terms tossed around but I didn't know they were different things. I thought they where the same, just a different way of putting the program on them?

 

Thanks

Link to comment
Share on other sites

Nope doesn't help me, other then a GROM is a special chip by TI.

 

A GROM holds a program and plays through the cart slot. A EPROM does the same. If GROMs are so unique then how are we able to use EPROMS? It seems they both do the same thing but they must not.

Link to comment
Share on other sites

Nope doesn't help me, other then a GROM is a special chip by TI.

 

A GROM holds a program and plays through the cart slot. A EPROM does the same. If GROMs are so unique then how are we able to use EPROMS? It seems they both do the same thing but they must not.

ROM and GROM in a cartridge are accessed differently. The CPU reads ROM directly. The CPU has to set the address of GROM first and then read a byte through a port. The GROM auto increment the address, so the CPU can continue to read subsequent bytes through the port. If the CPU wants to get data from elsewhere in the GROM, the CPU has to set the new address of GROM (to do this the CPU has to put 2 individual bytes at a port). Hope this helps a bit.

 

:)

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...