Jump to content
IGNORED

FlyGuy II


matthew180

Recommended Posts

Is anyone actually interested in the code for this game? Does anyone read assembly code anymore?

 

Matthew

 

Absolutely, I think we need a lot more source code! :)

If we want any newbies to give the TMS9900 a try, it certainly can't harm to let them take a look at existing code ;)

 

Would also want to take a look myself :D

Link to comment
Share on other sites

As requested, the source is attached. Compiles with Asm994a and should also compile with the real E/A, but I have not tested that. I try to keep my comments to less than 80 characters per line to work with the E/A if necessary.

 

The code is pretty well documented and easy to follow (of course I think so, I wrote it. ;-) ) There are never more than 1 or 2 levels of function calling, with the secondary calls mostly to things like VDP reading / writing helper functions. The main function is a simple state machine that polls the VDP vsync to provide a 1/60th of a second "tick" for the game timing. So really the game only "runs" during the vsync. There is support for doing processing while the display is being drawn, but in this case there is nothing to do.

 

Since, like most people, I like it when others are interested in things I have worked on, comments, questions, and praise are always welcome and appreciated. ;-)

 

Matthew

flyguy.zip

  • Like 1
Link to comment
Share on other sites

Argh, what's the keyboard equivalent for the fire button in Classic99? Never seems to be the same key twice. :(

 

It's been Tab consistently for 15 years now. :)

 

Note that in most games, "Q" also responds for Joystick 1, and some games map an alternate key (like period) as fire, but this isn't Classic99's fault. If you are using the keyboard for joystick emulation, it's arrow keys and tab. :) It's not configurable today.

 

This is documented in Classic99.txt. I know you guys bitched me out about my docs but "pretty" ones are coming, then there will be no excuses. ;)

Link to comment
Share on other sites

Argh, what's the keyboard equivalent for the fire button in Classic99? Never seems to be the same key twice. :(

 

It's been Tab consistently for 15 years now. :)

 

Heh heh, no worries Tursi, it those damn XB programmers (like me) who pick their own keyboard key to stand in for fire. I've been using Z and sometimes X, played another game that used A, and yet another with Q. Tab worked like a charm in Fly Guy II, and now I know that's the go-to key for proper games.

 

This version is fantastic Matthew, and I'm not just saying that because of the original. It's much improved - fast, smooth, and far better with continuous spider motion. Love the "Fly Guy appears" effect, as well as getting webbed when a spider catches you. And thanks for giving the Fly Guy sprite facing as well. The graphics are nicely improved too. Just needs some sound and it's a winner across the board, as far as I'm concerned.

 

Would love to see this on a cart some day! :thumbsup:

 

Oh, and you can use my real name on the startup screen if you like. Up to you.

Edited by The Codex
Link to comment
Share on other sites

It's been Tab consistently for 15 years now. :)

 

Note that in most games, "Q" also responds for Joystick 1, and some games map an alternate key (like period) as fire, but this isn't Classic99's fault. If you are using the keyboard for joystick emulation, it's arrow keys and tab. :) It's not configurable today.

 

This is documented in Classic99.txt. I know you guys bitched me out about my docs but "pretty" ones are coming, then there will be no excuses. ;)

 

Only 15, heh, that explains it then... ;-)

 

I always thought the Q key was hard wired to the fire button, and think, all along it was clever programmers.

 

Is it really documented in the txt file? I did read it, at least once.

 

Matthew

Link to comment
Share on other sites

This version is fantastic Matthew, and I'm not just saying that because of the original. It's much improved - fast, smooth, and far better with continuous spider motion. Love the "Fly Guy appears" effect, as well as getting webbed when a spider catches you. And thanks for giving the Fly Guy sprite facing as well. The graphics are nicely improved too. Just needs some sound and it's a winner across the board, as far as I'm concerned.

 

Thanks! There are a ton of things I could do, and some things I'm still planning. I hope to have some sort of "entrance" for the spiders as well, and I planned to have caught FlyGuy cocoons stay on the grid and be worth something like 1000 pts if you "free" your brethren.

 

I would really like a way, without using file I/O, to save the high score table. A nice battery backed RAM would be nice. :-) Maybe I could talk Tursi into letting me write to the ROM addresses (I spent a good hour early on in the development trying to figure out why my variable values were not changing. This is my first ROM based code so *usually* you can change your DATA and BYTE variables when your code is loaded into the low or high memory expansion.) If I could write to the ROM addresses then at least in the emulator the high scores could be saved. Also, as for the a real cartridge, I'm making mine with this neat chip I have from Dallas Semiconductor, a DS1225AD which is a RAM chip that has the pinout of a ROM, but also has a 10-year battery built in. They call it a Nonvolatile SRAM. It is much easier to work with than a real EPROM because erasing is simple (no UV or anything like that), and I can write to it in circuit if I want. They are not too expensive and I actually got mine as a free sample from Maxim-IC. :-)

 

Sound is planned, and no Owen I'm not pressuring you. :-) (Owen said, if he had time, that he would try to get me some in-game music.) Actually (shockingly) my wife was watching me test the game and she said "you know, I can do the music for that." She can sing and play the piano pretty well, and she was intrigued when I was helping Owen with the sound player for his Honeycomb Rapture game (my kids liked it too.) So, between either Owen or my wife, I'll get some music and sound effects. :-)

 

What I would really like is a way to interactively control the sound chip, kind of like a synth, so I can make my own sound effects. I know the sound chip is capable of amazing things and I don't think anyone "back in the day" pushed it (or the 9918A either) very hard. Does anyone know of such a program? Maybe those "sound tracker" things are what I'm looking for, but I never messed with one so I'm not sure.

 

Would love to see this on a cart some day! :thumbsup:

 

As soon as I get my 64K board soldered up I plan on testing it as a real cartridge. Anyone with an EPROM burner can make a cart. Or are you saying you think it would sell a few if I produce the carts myself?

 

Oh, and you can use my real name on the startup screen if you like. Up to you.

 

Okay, but, I don't know your real name (I'm not terribly observant)... ;-) I suppose I could check your profile, but a lot of people don't fill that out.

 

Matthew

Link to comment
Share on other sites

Thanks! There are a ton of things I could do, and some things I'm still planning. I hope to have some sort of "entrance" for the spiders as well, and I planned to have caught FlyGuy cocoons stay on the grid and be worth something like 1000 pts if you "free" your brethren.

 

I like that! It fits in with the more "friendly" game themes of the olden days, and adds an extra strategic element. Especially if the board still ends when all pellets are collected, which would mean having to race for the cocoon if the spiders are closing in on the last pellet.

 

Sound is planned, and no Owen I'm not pressuring you. :-) (Owen said, if he had time, that he would try to get me some in-game music.) Actually (shockingly) my wife was watching me test the game and she said "you know, I can do the music for that." She can sing and play the piano pretty well, and she was intrigued when I was helping Owen with the sound player for his Honeycomb Rapture game (my kids liked it too.) So, between either Owen or my wife, I'll get some music and sound effects. :-)

 

Owen is still living the high life on tour, the lucky bastiche, but should be back next week. Would be cool to hear what your wife comes up with too though. More musicians is always good in the game creation biz. We fight over them on most of the other game dev boards I hang out on.

 

As for your kids, between this and Honeycomb Rapture they must think all TI games are insect-based. ;)

 

What I would really like is a way to interactively control the sound chip, kind of like a synth, so I can make my own sound effects. I know the sound chip is capable of amazing things and I don't think anyone "back in the day" pushed it (or the 9918A either) very hard. Does anyone know of such a program? Maybe those "sound tracker" things are what I'm looking for, but I never messed with one so I'm not sure.

 

Trackers are typically for arranging tunes by stringing along byte values, sometimes graphically and sometimes manually. There are a lot of good ones for the C64 but I don't know of a TI one. The other thing you mention is a chip synth, which would definitely be a great thing to have on the TI as well. I concur that there is a lot of cleverness that could be done with that at low levels, along with exploiting the speech synthesizer more fully.

 

As soon as I get my 64K board soldered up I plan on testing it as a real cartridge. Anyone with an EPROM burner can make a cart. Or are you saying you think it would sell a few if I produce the carts myself?

 

Well, you'd have one guaranteed sale, but it's possible you could shift a few more than that, particularly at the fair. I'm sure the cart makers here like retroclouds could give a better answer on what is likely to sell and how many would have to be produced to make it worthwhile.

 

Okay, but, I don't know your real name (I'm not terribly observant)... ;-) I suppose I could check your profile, but a lot of people don't fill that out.

 

It is Lord Zorkag, The World Destroyer. I mean, Howard Kistler. :)

Link to comment
Share on other sites

Thanks for posting the source. Its surprisingly close to my present style. Quite a few things, structure and approach, are almost exactly as I do. My framework does however set aside a 16 level return address stack, and I use SWPB more, but thats about it.

 

I'm moving away from the static layout of control variables in Scratch Pad though. Makes it a bit "easier" to change something like Score from 2 bytes to 4 bytes.

 

;)

Edited by sometimes99er
Link to comment
Share on other sites

Thanks for posting the source. It’s surprisingly close to my present style. Quite a few things, structure and approach, are almost exactly as I do.

 

Cool. Now I know I'm doing something right. :-) I think a state machine makes sense for a game, and it is a natural evolution to arrive at that model. When I first started writing games back in the day, I could never figure out how to make everything happen "at once" like it did in the arcade. I didn't figure it out until years later.

 

My framework does however set aside a 16 level return address stack, and I use SWPB more, but that’s about it.

 

Yeah, I just don't need it any deeper than about 4. Personally I don't like to go too many levels (in any language) or I start to get lost in my own code. And following assembly is already hard enough. The only reason I set up the stack was because I found myself calling the VDP routines from within a 1st level call, and my very bottom level functions (like the VDP routines) do not bother with the return stack at all since they will never call to anything else. And, since all variables are global, there is very little need for parameter passing via a stack.

 

As for SWPB, I'll use it when I don't need the bytes back in their original order. But something like this, IMHO, is a waste:

SWPB R0
MOVB R0,@VDPWD
SWPB R0
MOVB R0,@VDPWD

 

That is simply two instructions you don't need.

 

I'm moving away from the static layout of control variables in Scratch Pad though. Makes it a bit "easier" to change something like Score from 2 bytes to 4 bytes. ;)

 

So... How do you do variables then, when making a ROM based game? Unless you are going to require the 32K RAM expansion, scratch pad is the only RAM we have. And with only 256 bytes to work with, I'm not sure I understand how you can get away from a static layout? Curious.

 

Matthew

Edited by matthew180
Link to comment
Share on other sites

So... How do you do variables then, when making a ROM based game? Unless you are going to require the 32K RAM expansion, scratch pad is the only RAM we have. And with only 256 bytes to work with, I'm not sure I understand how you can get away from a static layout? Curious.

A bit like this. And not a pretty sight.

 

score	equ	>8300
high	equ	score+2
level	equ	high+2

Changing size of score

score	equ	>8300
high	equ	score+4
level	equ	high+2

And adding a new variable

score	equ	>8300
score2 	equ	score+4
high	equ	score2+4
level	equ	high+2

Moving it all

score	equ	>a310
score2 	equ	score+4
high	equ	score2+4
level	equ	high+2

:cool:

Link to comment
Share on other sites

BSS - Yes

DATA/CODE - No, although the assembler inherited some module-coding elements from its mini-computer roots. Not many 99'ers make use of them.

 

What about the concept of segments? Just thinking that you could use the equivalent of the reserve memory directive e.g. "XXXX: .res 20" would reserve 20 bytes at starting at the label XXXX in a segment to make moving things around easier. The segment base address (controlled by the linker) would be the expansion RAM, scratch pad or wherever it was needed.

Link to comment
Share on other sites

BSS - Yes

DATA/CODE - No, although the assembler inherited some module-coding elements from its mini-computer roots. Not many 99'ers make use of them.

 

What about the concept of segments? Just thinking that you could use the equivalent of the reserve memory directive e.g. "XXXX: .res 20" would reserve 20 bytes at starting at the label XXXX in a segment to make moving things around easier. The segment base address (controlled by the linker) would be the expansion RAM, scratch pad or wherever it was needed.

 

Yes, the Linking Loader of the Editor-Assembler accepts the following:

 

AORG - Absolute Origin

RORG - Relocatable Origin

DORG - Dummy Origin

BSS - Block Starting with Symbol

BES - Block Ending with Symbol

PSEG - Program Segment

PEND - Program Segment End

 

These are also supported by the assembler, but the EA Loader won't accept them. You have to write a custom loader yourself:

 

CSEG - Common Segment

CEND - Common Segment End

DSEG - Data Segment

DEND - Data Segment End

 

Like I said, most 99'ers have never bothered to investigate these because the system isn't that great for segmented architecture. Nearly every TI application is converted to memory-image absolute files that are just chain-loaded into memory. Often referred to as 'E/A Option 5'.

 

Adamantyr

Link to comment
Share on other sites

I always thought the Q key was hard wired to the fire button, and think, all along it was clever programmers.

 

Now you've forced me to go look up which is the answer. :)

 

Columns 6 and 7 uniquely scan the joysticks, and no keyboard rows, so it is possible to read the joystick distinct from the keyboard. However, KSCAN unit 1 and 2 reads both 1/2 the keyboard AND the associated joystick fire button. The fire button returns a code of '18', which matches Q on joystick 1 and Y on joystick 2.

 

KSCAN is a little bit complex, but some interesting points. If fire is pressed, the keyboard unit scan is skipped (mode 1 and 2, that is), so the joystick can override the keyboard. The same indexing code is used to get the final return value as for keyboard scan. So any app that calls KSCAN will be unable to distinguish the fire button from Q/Y.

 

Is it really documented in the txt file? I did read it, at least once.

 

Two places even. Under the keyboard section:

 

The arrow keys normally return FCTN+E/S/D/X. If joystick emulation is set to

keyboard, and the program scans the joystick, then these keys (and Tab) respond

to the joystick request only. After about 3 seconds if the joystick is not

scanned again, they return to being keyboard keys.

 

And under the configuration reference, joystick:

 

joy1mode (and joy2mode for joystick 2)

0 Keyboard (arrow keys and tab)

1 PC Joystick 1

2 PC Joystick 2

 

Moving on...

 

Trackers are typically for arranging tunes by stringing along byte values, sometimes graphically and sometimes manually. There are a lot of good ones for the C64 but I don't know of a TI one.

 

I ported the ePSGMod format to the TI... my code is here: http://harmlesslion.com/software/psgmod

The original tracker is here: http://www.kontechs.de/product?name=mod2psg2

And the sample program is built into Classic99 under Cartridge->Apps->EPSGMOD Sample

SPECTRA has also built the player in. :)

 

However... the author hasn't supported the tracker well.. he gave me the 2.05 code years ago and still hasn't updated the tracker itself on his site. That, plus the license terms, has me thinking we might want to just roll our own. The attraction of this tracker was the ability to cross-pollinate with the Master System crowd (and hell, Coleco and MSX can use it too), but it doesn't seem to be heavily used. Besides Shiru's (amazing) tracks, I've seen very little else.

Link to comment
Share on other sites

These are also supported by the assembler, but the EA Loader won't accept them. You have to write a custom loader yourself:

CSEG - Common Segment

CEND - Common Segment End

DSEG - Data Segment

DEND - Data Segment End

Like I said, most 99'ers have never bothered to investigate these because the system isn't that great for segmented architecture. Nearly every TI application is converted to memory-image absolute files that are just chain-loaded into memory. Often referred to as 'E/A Option 5'.

 

Well.. that, and the fact that the loader doesn't support any of the segments except the program segment, which is the default anyway.

 

Having actual segment support would be nice for some instances - like building ROMs. :)

Edited by Tursi
Link to comment
Share on other sites

A bit like this. And not a pretty sight.

 

score	equ	>8300
high	equ	score+2
level	equ	high+2

Changing size of score

score	equ	>8300
high	equ	score+4
level	equ	high+2

And adding a new variable

score	equ	>8300
score2 	equ	score+4
high	equ	score2+4
level	equ	high+2

Moving it all

score	equ	>a310
score2 	equ	score+4
high	equ	score2+4
level	equ	high+2

:cool:

 

Ah, I see. kind of like an ENUM in C. That would be nice to have, maybe I'll do something like that in my assembler (if I quite writing games long enough to finish it.) A construct that lets you designate a start address, then simply indicate how many bytes each label should represent. hmm.

 

But for the ROM based games, I don't see much use in moving the variables. I can see where it would be nice for changing the size of variables later, but most of the time I know the range of the data when I designate the label, so its size is not going to change much.

 

Matthew

Link to comment
Share on other sites

Columns 6 and 7 uniquely scan the joysticks, and no keyboard rows, so it is possible to read the joystick distinct from the keyboard. However, KSCAN unit 1 and 2 reads both 1/2 the keyboard AND the associated joystick fire button. The fire button returns a code of '18', which matches Q on joystick 1 and Y on joystick 2.

 

Ah that explains it, I don't KSCAN (probably never will either.)

 

Two places even. Under the keyboard section:

 

The arrow keys normally return FCTN+E/S/D/X. If joystick emulation is set to keyboard, and the program scans the joystick, then these keys (and Tab) respond to the joystick request only. After about 3 seconds if the joystick is not scanned again, they return to being keyboard keys.

 

And under the configuration reference, joystick:

 

joy1mode (and joy2mode for joystick 2)

0 Keyboard (arrow keys and tab)

1 PC Joystick 1

2 PC Joystick 2

 

Yeah, but the word "tab" is always in parens, and you never specifically say "TAB is the fire button". :-)

 

I ported the ePSGMod format to the TI... my code is here: http://harmlesslion.com/software/psgmod

The original tracker is here: http://www.kontechs.de/product?name=mod2psg2

And the sample program is built into Classic99 under Cartridge->Apps->EPSGMOD Sample

SPECTRA has also built the player in. :)

 

Yup, I found that tracker last night and messed around with it a little. Very clunky and hard to use IMHO. I don't know what he used to write that with, but a language that would have allowed him an easier and more standard interface would have been a better choice, again IMHO. Either way, it is better than nothing and lets me mess with the sounds quickly and with reasonable feedback. A few of the sounds are pretty nice, however the best sounding one seems to use a frequency setting of 1/2 of the real Master System, so those sounds would not be possible on the real gear (lower frequency for better sounding bass tones.) I wonder if the SMS uses the same frequency as the 99/4A?

 

Matthew

Link to comment
Share on other sites

Now that I think about it, instead of this:

 

SCORE EQU >8320
TIMER EQU >8322
LOCXY EQU >8324

 

* Or even this:

 

VARS  EQU >8320
SCORE EQU VARS
TIMER EQU SCORE+2
LOCXY EQU TIMER+2

 

I think this should work, no?

 

* Scratch pad RAM variables
      AORG >8320
SCORE  BSS  2
TIMER  BSS  2
LOCXY  BSS  2
* start byte variables
LIVES  BSS  1
.
.
.
      EVEN

* Start ROM code
      AORG >6000

* ROM constants
BONUS  DATA >10000
.
.
.

 

I don't see why that would not work, other than Asm994a messing it up (Asm994a does not support BES, by the way.) I'll give the benefit of the doubt though and give it a try. :-)

 

Matthew

Edited by matthew180
Link to comment
Share on other sites

Well, Asm994a won't do it. I pukes all over itself when you use an AORG other than >6000 and ask it to make a cartridge binary. It makes the correct references though. However, it seems that Asm994a requires a BSS to be on an even boundary, and pucks on itself when you have odd BSS counts in succession. This does not assemble with it:

 

      AORG >8320
SCORE  BSS  2
LIVES  BSS  1
PILLS  BSS  1
LEVEL  BSS  1

 

However, remove the PILLS and LEVEL lines and it does compile, well, it still gives the address range error. I wonder what the real E/A would do? Time to go see.

 

Matthew

Link to comment
Share on other sites

Well, Asm994a won't do it. I pukes all over itself when you use an AORG other than >6000 and ask it to make a cartridge binary. It makes the correct references though. However, it seems that Asm994a requires a BSS to be on an even boundary, and pucks on itself when you have odd BSS counts in succession. This does not assemble with it:

 

      AORG >8320
SCORE  BSS  2
LIVES  BSS  1
PILLS  BSS  1
LEVEL  BSS  1

 

However, remove the PILLS and LEVEL lines and it does compile, well, it still gives the address range error. I wonder what the real E/A would do? Time to go see.

 

Matthew

Ah, I was thinking about trying that out too. Would be more elegant. I may be wrong, but I think I got the idea from the source of Munch Man.

 

It’s just that size and number of related (groups of) variables, pointers, flags or arrays change a bit in my iterative process. Or maybe it’s the lack of focus (different projects etc.).

 

:)

Link to comment
Share on other sites

I would really like a way, without using file I/O, to save the high score table. A nice battery backed RAM would be nice. :-) Maybe I could talk Tursi into letting me write to the ROM addresses (I spent a good hour early on in the development trying to figure out why my variable values were not changing. This is my first ROM based code so *usually* you can change your DATA and BYTE variables when your code is loaded into the low or high memory expansion.) If I could write to the ROM addresses then at least in the emulator the high scores could be saved. Also, as for the a real cartridge, I'm making mine with this neat chip I have from Dallas Semiconductor, a DS1225AD which is a RAM chip that has the pinout of a ROM, but also has a 10-year battery built in. They call it a Nonvolatile SRAM. It is much easier to work with than a real EPROM because erasing is simple (no UV or anything like that), and I can write to it in circuit if I want. They are not too expensive and I actually got mine as a free sample from Maxim-IC. :-)

 

I could probably add a new ROM image type for that once it's proven to work on hardware. :) The concept is simple enough.. just have to make sure there's no extra hardware required that would affect emulation.

Link to comment
Share on other sites

Ah, I see. kind of like an ENUM in C. That would be nice to have, maybe I'll do something like that in my assembler (if I quite writing games long enough to finish it.) A construct that lets you designate a start address, then simply indicate how many bytes each label should represent. hmm.

 

Actually, Matthew, if you just support segments (using the TI naming scheme or something else), that's really what they are for. The idea of segments is just that each segment has its own address counter, and you switch between segments freely in your code. Then when you assemble or link, that's when you tell the computer what address to base each segment at. This makes it easy to write code that works both in RAM and on cart, you just change the data segment and program segment addresses around. :)

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