Jump to content

skywaffle

Members
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

100 Excellent

About skywaffle

  • Rank
    Star Raider

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Oh I certainly would consider Tron Deadly Discs and AD&D Cloudy Mountain to be twin stick like games. However, with a single controller, you can't quite register certain number presses and disc directions at the same time, limited how fast and frantic the game can play. Also I was trying to emulate the manic, claustrophobic feeling of Robotron; being surrounded by a ton of enemies at once. I still haven't investigated the controllers enough, but am hoping the 16 direction control and shots should be able to be implemented without too much effort. I will also look into adding inverted controls as well.
  2. Thank you, it's been fun to see it come together as far as it has, and just to see something like it run on the Intellivision. For the foreground element, things get a little complex. I try to organize all the grams into background (no collision), then foreground (also no collision), and lastly solid tiles (walls, floors, etc that would use collision) The foreground sprite is something that turns on and off dynamically. I use sprite 0 since it overlaps all other sprites, and the gram is solid (all 1s). Basically as the player moves, the backtab in front of the player is looked at for grams that are greater or equal to the reference point for foreground grams. Once this is found, a static x and y position is established and sprite 0 gets enabled using the "behind" flag. Once enabled, distance from the player to the foreground sprite is checked, and if greater than a set amount, it turns off the sprite Here is the code I use. X and Y reflect the player's position, and #flip is the direction the player faces. TEMP = (X / 8 ) * 8 + 8 TEMPY = (Y / 8 ) * 20 IF FOREGROUND_OBSTRUCTION_X = 0 THEN SPRITE 0,0 IF #FLIP <> 0 THEN OX = X + 4 ELSE OX = X - 16 END IF #TEST = #BACKTAB ((OX / 8 ) + TEMPY) AND (GRAM + FGBG_CARD_DATA_MASK) IF #TEST >= $0908 THEN FOREGROUND_OBSTRUCTION_X = (OX / 8 ) * 8 + 8: OBSTRUCT_Y = Y - 3 ELSE SPRITE 0, FOREGROUND_OBSTRUCTION_X + VISIBLE, OBSTRUCT_Y + ZOOMY8, SPR63 + SPR_BLACK + BEHIND IF #FLIP = 0 THEN IF X > FOREGROUND_OBSTRUCTION_X THEN IF X - FOREGROUND_OBSTRUCTION_X > 18 THEN FOREGROUND_OBSTRUCTION_X = 0 ELSEIF FOREGROUND_OBSTRUCTION_X - X > 9 THEN FOREGROUND_OBSTRUCTION_X = 0 END IF ELSE IF X > FOREGROUND_OBSTRUCTION_X THEN IF X - FOREGROUND_OBSTRUCTION_X > 11 THEN FOREGROUND_OBSTRUCTION_X = 0 ELSEIF FOREGROUND_OBSTRUCTION_X - X > 13 THEN FOREGROUND_OBSTRUCTION_X = 0 END IF END IF END IF As far as the sprites go, I am still undecided how to approach enemies. I figured in areas with enemies, I could remove foreground elements and have that sprite available to use and possibly multiplex to display both swords for the player and enemy. I still am unsure how faithful I want to be to Prince of Persia to be honest. I have contemplated doing something different, and just having traps, keys, doors, and various puzzle elements. It could make for an interesting adventure experience, but I haven't given up yet.
  3. Hello everyone, For the past few days, I kept wondering about having some game that uses both Intellivision controllers and plays like a twin stick type shooter, such as Robotron 2084. I honestly don't know if anyone else has done something like this, but I figured I would see how fast I could whip up a very simple game as a proof of concept. The game is pretty rough, as I've only put an hour or so into it, but I thought others might get a kick out of it. On the title screen, you can switch between using a single controller or twin controllers by pressing 1 or 2, and then the top left button to start the game. In single controller mode, the top left button shoots in whatever direction you are moving, and bottom left button locks the shooting direction for sidestepping. In the twin controller mode, controller 1's disc moves, and controller 2's disc shoots. I only have 8 directions currently, but would like to spend more time figuring out using all 16 directions. The goal currently is to destroy all the "robots" , and you can pick up money for extra points. Every level beaten adds more to destroy and collect. Source code is included for those interested, although it is a bit poorly written, and not documented too well. robo01.bas robo01.rom
  4. You're welcome. If you are not changing the values of these arrays, you can also reference the tables directly rather than using the limited RAM to store what is already in ROM.
  5. I thought restore only pointed to one set of data statements, although it is not a command I typically use. You could do something like this instead to store the contents of the two tables into two separate arrays: DIM sqx(10) DIM sqy(10) read_array: FOR x = 0 to 9 sqx(x) = table_x(x) sqy(x) = table_y(x) NEXT x table_x: DATA 24,24,96,144,144,80,24,32,24,32 table_y: DATA 64,16,32,24,80,72,56,64,24,16
  6. For those that might be interested. I uploaded a video on Youtube showing a portion of Stage 5 during some play testing / bug fixing. https://www.youtube.com/watch?v=fgChQ-yaHYI
  7. Here is another animation that might be a bit more organized. As I worked on different animations, I would find nicer ways to work some of the tables and try to keep the overall sprite definitions the same between every animation. In the actual game, all the tables are combined, and the sprites are all set up with a subroutine, I also have an ON / GOSUB routine that will call specific logic required for certain animations (like being able to grab a ledge while jumping). Here is the set of animations that have been flattened (originally it was layered to allow for easily repositioning and tweaking of individual sprites) Once I have run out of patience working on graphics, or feel satisfied with what I have, I reorganize the graphics like so: The pants are the first two grams, then arms, then turban/vest, and then shoes. After that I recolor the image to two colors so Intycolor won't invert any of the bitmaps. Once this is done, I run Intycolor with the arguments -b -a to convert everything to IntyBASIC, and lastly move all the data statements from the generated BAS file into the program attached and get to work on setting up the correct offsets in the various x and y tables. pop_climb5.bas
  8. The x/y offset table values are done through trial and error. I use paint.net to create all the graphics (using layers to reflect each sprite), and with that I can determine if each frame will have a double wide sprite which I can easily set in the tables. pop_jump was the file for when I converted the BMP for all the animation frames into a BAS file using INTYCOLOR.EXE. I just take all the bitmaps and copy them to another file. As I would tweak the animation frames, or redraw certain graphics, I would always have one file with raw bitmaps, and a second for the animation routines. I was trying to limit the number of sprites used, because I use an additional sprite as a mask for foreground elements, and that only leaves three to be used for an enemy sprite, or possibly falling platforms. On the jump animation, his feet are so far apart, there was no easy way to draw both without using an additional sprite, or multiplexing, however that is the only animation I have that uses that. #CHRCOL5 really hasn't been used for anything, and I should have removed it, early in development I was experimenting with using BEHIND, but I had found a better method to make the character disappear behind objects.
  9. That's correct. Attached is an example of how all the animation is done. It was thrown together just for testing animation frames and aligning the sprites for each frame before being put into the game Up and down will change the animation frame and left and right will change the direction pop_jump2.bas
  10. This is all being done in IntyBASIC, and runs fine on stock Intellivision hardware. The main character is done with 4 sprites, using 7 and occasionally 8 grams. These grams are redefined and the sprite positions are adjusted for each frame. More compromises will likely be made to have the sword fighting elements, and even drawing an additional character on the screen, as well as having falling platforms. The 8 sprite limit, along with 64 unique grams will make things difficult.
  11. Thank you very much! I plan to upload this and the source soon for people to play around with, but have been just doing some various touch ups. I will also be posting a new video of it on Youtube hopefully in the next day or so showing the progress on it, it's come a ways since the previous video, much of the platforming type aspects are working pretty nicely (climbing up/down, jumping, walking and running).
  12. Thank you! I have since added a bit more to make it closer to the original game. Some bugs have been fixed, UFOs, and missile enemies have been added, as well as more animation, explosions for enemies, and the backgrounds now change color when the level increases. The score doesn't move backwards yet, although I am uncertain if I want to keep that from the original game. I am still trying to determine how I can add additional content, but will probably work towards original ideas in a later release. I keep leaning towards having stages work differently, maybe each stage is a couple minutes in length and between stages having a shop to purchase upgrades, such as speed ups, hyperspace, extra lives, and larger weapons using money earned from destroying enough enemies. astro03.zip
  13. Hello, I was just thinking about how most Mattel programmed Intellivision games played at such a choppy framerate, and then one thing led to another, and I started making an Astrosmash clone with the goal of smoother gameplay, and maybe a steeper difficulty curve. This is not finished, but figured maybe someone might be interested in trying it out. There is a lot missing still, and I keep contemplating different ideas to further enhance the game, once the base gameplay is in tact. Some of these ideas are a challenge mode (survival for so many seconds, no shooting, game over after so many meteors get past), power ups (wide shot, shield, bombs), shops in between stages to purchase more lives or power ups, different stage backgrounds, more enemy types (still missing the UFO and the homing missile, but figured enemy ships and maybe large bosses could be a thing). Anyways, just some ideas, I have a lot of nostalgia for the original game, so hopefully no one is offended by this. A ROM image and source is attached. ASTRO02.zip
  14. Is it possible to alter the screen position mid frame? I thought on other consoles, some parallax type effects were achieved through altering the horizontal screen position on different scanlines in between the wait cycle.
  15. Hello, I was just curious if there any way to pause and resume music playback in IntyBASIC? I was thinking there must be a way to peek / poke the tracker location, just not sure if that is possible or not. Thanks, Matthew
×
×
  • Create New...