Jump to content

Photo

FlyGuy II


106 replies to this topic

#26 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 9, 2010 9:03 AM

Excellent stuff!

Oh, and for what it is worth, you might want to take a peek SPECTRA (shameless plug :D) as it offers some routines for task scheduling, handling sprites, etc.

Anyway, great to see a new assembler game in development!
.. and what is even better hope to see this as a full tutorial ;)


Spectra is pretty nice, and people should check it out for sure. As for me though, I *want* to write all this myself. For me it's more about the coding and learning the guts of the machine than the end result.

I'm trying to put together some sort of tutorial, but more in the form of a book though, since I tend to get verbose. ;-)

Matthew

#27 The Codex OFFLINE  

The Codex

    Dragonstomper

  • 573 posts
  • Location:Richmond, VA

Posted Tue Mar 9, 2010 9:14 AM

By the way, what acronyms are you not sure about?


Mostly BLWP and VDP. I think I've somewhat intuited what they apply to, but am unsure exactly what they stand for. When I did a web search for "assembler BLWP", the first result that came back was this thread. :)

#28 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 9, 2010 10:34 AM

Haha, well this thread is the end-all be-all of information on the Internet. :-)

VDP == Video Display Processor. It is really a generic term, but not used much any more. Now days we just say Radeon or gForce. In the TI, the VDP is the TMS9918A which is a single chip that takes care of displaying the video image. The 9918A also has its own RAM, typically called VDP RAM. The CPU can get access to the VDP RAM but it has to do so by going *through* the VDP, which can be a slow process since the VDP is almost always busy drawing the screen. The 9918A supports a few graphic "modes" as well as the 32 sprites. However, there is a limitation on the number of sprites the VDP can display on a single horizontal scan line (due to the amount of time the VDP has to process a horizontal scan), so after 4 sprites are displayed on a given scan line, the VDP stops drawing sprites on that line. This is the "4 sprite" limitation you see us referring to. The VDP does *not* automatically move the sprites, and the auto-sprite movement you might read about on the TI is done by the one and only ISR (interrupt service routine) in the console. The ISR is triggered by the VDP vsync 60 times per second, and it can be disabled (which is usually done for assembly games.)

BLWP == Branch and Load Workspace Pointer. It is a machine instruction (assembly language mnemonic) that was primarily designed for doing OS context switching since the TMS9900 was most used in TI's mini computers. It is one of a few ways to do function calling in assembly, and definitely the slowest way to do functions. It has a few advantages though that depending on the circumstances can be worth it.

You can read about the gritty details in the EA (Editor Assembler) manual or the TMS9900 Datasheet. I'm pretty sure both are available on the WHTECH FTP site, or I think there is a torrent set up too? Anyone? The EA manual was the "big book" that came with the Editor/Assembler package and is the de-facto reference for the 99/4A (although not complete.) The PDF I have is a scan of every page and weighs (virtually speaking) as much as the real book. The 9900 Data Manual is the datasheet that TI put out for engineers to build computers with the 9900 CPU and has all the low down details about instruction execution, timing, internal operation, interfacing, etc. I use both quite a bit, and the especially the data manual when working on my emulator.

Hope this helps some.

Matthew

#29 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,222 posts
  • Location:Denmark

Posted Tue Mar 9, 2010 11:35 AM

Actually the simplest solution is to just use Classic99 since I know you ignore the 4 sprite limit. ;-)

I don't think that's all true anymore. Tursi ?

:)

#30 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,693 posts
  • Location:Germany

Posted Tue Mar 9, 2010 1:27 PM

You can read about the gritty details in the EA (Editor Assembler) manual or the TMS9900 Datasheet. I'm pretty sure both are available on the WHTECH FTP site, or I think there is a torrent set up too? Anyone? The EA manual was the "big book" that came with the Editor/Assembler package and is the de-facto reference for the 99/4A (although not complete.) The PDF I have is a scan of every page and weighs (virtually speaking) as much as the real book. The 9900 Data Manual is the datasheet that TI put out for engineers to build computers with the 9900 CPU and has all the low down details about instruction execution, timing, internal operation, interfacing, etc. I use both quite a bit, and the especially the data manual when working on my emulator.


Both the Editor/Assembler manual and 9900 Data Manual PDF's can be referenced from the development resources sticky thread. ;)

#31 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,572 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Mar 9, 2010 6:12 PM

Actually the simplest solution is to just use Classic99 since I know you ignore the 4 sprite limit. ;-)


You underestimate me again, Batman! Classic99 has supported sprite flicker since 22 Jun 2009. ;) The method used to calculate it is hacky, but the results are 100% correct. ;)

#32 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 12:59 AM

Playable WIP (work in progress). Arrows (joystick) to move, fire button to start a new game (controls are like a coin-op). Extra life at 10,000 pts, level stays at 5 once you reach level 5. FlyGuy and the Spiders get faster on each successive level. The timer is added to your score after each level.

To run: unzip and using Classic99, select the file as a User Cartridge. Press 2 2.

Matthew

Attached Files



#33 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 10,678 posts
  • Location:Hustisford, WI

Posted Tue Mar 16, 2010 1:56 AM

Thank you for this Matthew. It's a real pleasure seeing your assembly work. :)

#34 The Codex OFFLINE  

The Codex

    Dragonstomper

  • 573 posts
  • Location:Richmond, VA

Posted Tue Mar 16, 2010 7:03 AM

Woot, looking forward to trying this out tonight! :thumbsup:

#35 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,693 posts
  • Location:Germany

Posted Tue Mar 16, 2010 7:30 AM

Excellent work Matthew! This is fun.

Now that assembly language is used it would be cool to move the flyguy pixel by pixel (but still let him snap to the grid)

Dunno if someone asked this before, but why not make a homebrew cart out of this ?

Either way, looking forward playing the final version :D

#36 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,693 posts
  • Location:Germany

Posted Tue Mar 16, 2010 7:38 AM

22600 :D

Attached File  flyguy_ii.jpg   68.9KB   11 downloads

#37 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 7:46 AM

The original was character based, so I wanted to duplicate that first. I started on the sprite-based version but decided to get the character version playable and somewhat complete first. The response over this version will heavily dictate whether I do the modification to sprites or not. Just moving at fixed 8-pixel intervals is no big deal, but my plan was to let FlyGuy and the spiders move freely at a pixel level and simply be confined to the grid (web). This means you could reverse direction at the pixel level, whereas moving at fixed 8-pixel intervals means FlyGuy would have to complete the full 8-pixel move before you could reverse direction or stop. The unconfined movement is what we are used to in the arcades, but it is also a lot harder to implement.

I'm still not sure how to take the levels further either. I don't think hand made levels is the answer, especially since they take a lot of data. Finding a way to generated them like the original version would be required, or having fixed levels with more of a design and other challenges. Having the spiders jump or dangle on webs, and FlyGuy "fly" (maybe for a limited time, or a limited number of times) would be other alternatives.

I don't really like the FlyGuy "entrance" either, but I needed a way to bring FlyGuy's location to the attention of the player, since his start location is random each time and he was had to location at the start of a level. I just could not come up with anything more interesting right the moment.

Matthew

#38 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,693 posts
  • Location:Germany

Posted Tue Mar 16, 2010 7:58 AM

I don't really like the FlyGuy "entrance" either, but I needed a way to bring FlyGuy's location to the attention of the player, since his start location is random each time and he was had to location at the start of a level. I just could not come up with anything more interesting right the moment.
Matthew


Are you kidding? That is one of the coolest thing of the game :D

#39 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 8:26 AM

Well, it is a total hack. ;-) Since I don't have enough RAM (other than copying back and forth to/form VDP RAM... ugh) to store the two paths across the screen, I have to redraw the level, pills, an spiders after the effect and there is a quick flash of the display when that happens. If the effect is that acceptable, maybe I'll redo it the *right* way and see if I can make it non-destructive so it looks nicer. :-)

Matthew

#40 The Codex OFFLINE  

The Codex

    Dragonstomper

  • 573 posts
  • Location:Richmond, VA

Posted Tue Mar 16, 2010 8:36 AM

Just moving at fixed 8-pixel intervals is no big deal, but my plan was to let FlyGuy and the spiders move freely at a pixel level and simply be confined to the grid (web). This means you could reverse direction at the pixel level, whereas moving at fixed 8-pixel intervals means FlyGuy would have to complete the full 8-pixel move before you could reverse direction or stop. The unconfined movement is what we are used to in the arcades, but it is also a lot harder to implement.


I've got a technique for that, came up with it for the Solar Fox remake I never released. Like the arcade original, you move on a grid but can only make left/right turns at grid interesections. I also use a small loop to snap the player back to the closest gridpoint if they stop moving. Let me know if you want to take a look at this, it's in Java but is pretty easy to suss out from the sources.

#41 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,693 posts
  • Location:Germany

Posted Tue Mar 16, 2010 8:40 AM

Well, it is a total hack. ;-) Since I don't have enough RAM (other than copying back and forth to/form VDP RAM... ugh) to store the two paths across the screen, I have to redraw the level, pills, an spiders after the effect and there is a quick flash of the display when that happens. If the effect is that acceptable, maybe I'll redo it the *right* way and see if I can make it non-destructive so it looks nicer. :-)

Matthew


Well, I guess you could do the below:
1. Draw the screen
2. Copy the screen
3. Switch VDP name table pointer to copied screen
4. Do your funky animation stuff on copied screen
5. Switch VDP name table pointer to the original screen

#42 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 10:38 AM

I've got a technique for that, came up with it for the Solar Fox remake I never released. Like the arcade original, you move on a grid but can only make left/right turns at grid interesections. I also use a small loop to snap the player back to the closest gridpoint if they stop moving. Let me know if you want to take a look at this, it's in Java but is pretty easy to suss out from the sources.


I'd like to avoid the snapping or forcing to a character boundary except during turns where you have to be aligned +/- 4 pixels or so. Getting it working is not really the problem, getting it working in a slick efficient way is the problem. :-)

I'm using PacMan as a template, and if anyone has not done so, I highly recommend you read The Pac-Man Dossier on Gamasutra. It is one of the most excellent articles I have ever read about classic coin-op games. Absolutely amazing what is actually going on inside the game and makes my efforts feel less than adequate.

Matthew

#43 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 10:45 AM

Well, I guess you could do the below:
1. Draw the screen
2. Copy the screen
3. Switch VDP name table pointer to copied screen
4. Do your funky animation stuff on copied screen
5. Switch VDP name table pointer to the original screen


Even doing that does not solve the problem. When the lines of FlyGuys are being erased, the "proper" thing to do would be to restore what was under them to begin with. Having a second screen does not help with that. Since I don't have the RAM in the console to store the 54 characters I need (I can't use the 32K expansion since I'm trying to keep this as a console cartridge that will run on an unexpanded system), I'd have to copy in chunks from the VDP into a small buffer in CPU RAM, then back into VDP RAM. Then when erasing the FlyGuys, I'd have double the VDP accesses to get the original characters from VDP RAM and put them back in their original location in VDP RAM. I know what to do, I just need to do it. But I didn't want to spend that much time on it if the effect was lame or confusing to the player.

Matthew

#44 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,572 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Mar 16, 2010 5:00 PM

Even doing that does not solve the problem. When the lines of FlyGuys are being erased, the "proper" thing to do would be to restore what was under them to begin with. Having a second screen does not help with that. Since I don't have the RAM in the console to store the 54 characters I need (I can't use the 32K expansion since I'm trying to keep this as a console cartridge that will run on an unexpanded system), I'd have to copy in chunks from the VDP into a small buffer in CPU RAM, then back into VDP RAM. Then when erasing the FlyGuys, I'd have double the VDP accesses to get the original characters from VDP RAM and put them back in their original location in VDP RAM. I know what to do, I just need to do it. But I didn't want to spend that much time on it if the effect was lame or confusing to the player.


You say you have it already, but as a suggestion.. when you have tons of ROM and little RAM, use the ROM. It might be helpful to just predefine the screens in the ROM itself, then you can just copy right out of them when you need to erase. :)

#45 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 6:26 PM

Okay, here is another update with the FlyGuy "entrance" done right. :-) Fixed a bug or two as well. Small note about entering initials, use the fire button (tab key in Classic99) to move to the right (the left and right joystick work too), but you have to hit the fire button in the last character to commit the initials.

Matthew

Attached Files



#46 The Codex OFFLINE  

The Codex

    Dragonstomper

  • 573 posts
  • Location:Richmond, VA

Posted Tue Mar 16, 2010 6:44 PM

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

#47 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Tue Mar 16, 2010 7:58 PM

The TAB key is joystick "fire" in Classic99. Not sure if that can be remapped or not. I found it by trial and error. :-)

Matthew

#48 The Codex OFFLINE  

The Codex

    Dragonstomper

  • 573 posts
  • Location:Richmond, VA

Posted Wed Mar 17, 2010 7:02 AM

Gravy, I'll give that a try tonight. Thanks!

#49 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,621 posts
  • Location:Castaic, California

Posted Wed Mar 17, 2010 9:31 AM

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

Matthew

#50 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 10,678 posts
  • Location:Hustisford, WI

Posted Wed Mar 17, 2010 10:20 AM

Matthew,
I am not yet an assembly programer, but I tried to get my hands on as much "commented" source as I can. I love Filips stuff he put out on Pitfall. It helps me understand how the computer "reads" so to speak. ;) even though the source cannot really run by itself--- it must be assembled into object code. But I would certainly be interested in seeing your source... If you're offering. :)

Edited by Opry99er, Wed Mar 17, 2010 10:22 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users