skywaffle

When I first began working on Dragon Quest, I originally had the character movement and text speed faster, as well as omitting some of the excessive menus, but as I got further along with development, I decided I liked the idea of replicating what we would have had back in the day. In some ways the flaws have their own charm. If you want quality of life, you can easily play one of the mobile ports of Dragon Quest. When I think of older consoles and computers, having the clunkier gameplay just feels appropriate. Not to mention having to draw out maps on graph paper, or writing down clues for old RPGs as opposed to the hand holding of newer titles.

All character stat values for each level are predetermined, and contained in a table. However, based on the character's name, two of the four stats (Strength, Agility, HP, and MP) are reduced. The "Excellent move! It is dodging!" is a flaw in the original NES game as well; the critical hit is determined before checking monster evasion.

I didn't even realize that those were PPC; I only noticed the PPC requirement on Jzintv. I'm always looking for something (potentially productive) to do with my Amiga 3000.

Well, I mean one for a 68k CPU. That's just a bit too high end for me.

Wow! I definitely want to try this. If only IntyColor supported IFF files. It'd make for some pretty easy development (Outside of not having an Amiga compatible Intellivision emulator)

For quick testing, I always use JZINTV. I don't believe there is a more accurate Intellivision emulator around.

Oh, I didn't think about trying to map out ECS. If this project manages to get far enough, I am fairly certain I'll need the available address ranges that ECS uses anyways for ROM space.

Hmm, I had played it on my LTO without any issues, however, I was just using a BIN/CFG. I attached these if you want to try that instead. contra.bin contra.cfg

Thanks! I don't know if this would be developed into a full port, or maybe an original run and gun game. Regardless, it's always fun trying to imagine what some nostalgic games could have looked like demade on the Intellivision.

Happy New Year everyone, During the last week I was goofing around in IntyBasic and developed this. It's a rough work in progress demo of a Contra clone. There are bugs, slow down, and only one stage, but thought it had some potential. Enjoy! Matthew CONTRA.rom

Thank you! I wanted it to feel as close as possible to the original game. Playtesting has required playing both versions side by side, just to verify that all formulas feel accurate, and one version doesn't come off easier or more difficult than the other. I've been really excited about seeing a full JRPG on the Intellivision. I originally wanted to do a port of Final Fantasy, but felt that Dragon Warrior would be much easier to accomplish. It still been a challenge to make everything work though, and only in the last month has it begun to feel like a game.

Yeah, this doesn't currently utilize JLP for flash save support, so a password is used to continue. The original Japanese version also used a password, although this one is longer due to having fewer characters for storing data.

All the days and evenings I've spent on it, I feel the same way. LOL

Hello, I had not really considered releasing a demo, but if people are interested I suppose I could do something. I am still hoping to get this finished, but progress has been slow this year.

I update the variables for any sprite positions and then redraw all sprites at that point. Is the jitter occurring each frame, or only on the frame the backtab is shifted?

In my projects, my flow is something like below: START: Update the scroll offset variable. Check if the offset > 7 and if so, set a variable for screen shifting (IF OFFSET_X > 7 THEN OFFSET_X = OFFSET_X - 8: SCREEN_SHIFT = 1) SCROLL OFFSET_X, 0, SCREEN_SHIFT Update SPRITE positions WAIT Check sprite collisions IF SCREEN_SHIFT <> 0 THEN SCREEN_SHIFT = 0: SCREEN etc GOTO START

I always update all sprites on screen after the SCROLL statement, and before the WAIT. Whenever you shift the backtab, you will also need to offset your people by 8 pixels.

Off topic, but you can further simplify your code and avoid all the redundant conditional statements for drawing the screen for the various streets by using a table containing offsets for the starting point of each area. This can be very beneficial if your game grows larger. For example, if your all four street map data (screen_0, screen_1, screen_2, and screen_3) are made up of 40x12 tiles, you could have something like this: stage_offset: DATA 0 ' Street 0 DATA (40*12) ' Street 1 DATA (40*12) + (40*12) ' Street 2 DATA (40*12) + (40*12) + (40*12) ' Street 3 If the sizes are different, just make the changes accordingly, just keeping in mind to carry over the offset from the previous line. Instead of having all the conditional statements, have a single SCREEN command like this: SCREEN street_maps, stage_offset(street) + #muv+19, 19, 1, BACKGROUND_ROWS, #LANDSCAPE_WIDTH

I don't know if you had resolved this yet, but typically when I am doing scrolling in games, I have my SCROLL command run, a WAIT statement after this (at some point in the loop), and then update the SCREEN. When you use SCROLL to shift the screen, the shift does not occur immediately, but will after the WAIT.

You could possibly come up with a work around, such as displaying the stats if the screen is stationary for a length of time, and then blanking them out once the screen begins to scroll again. Maybe not though if there is a lot of continual scrolling.

Unfortunately SCROLL ,,X shifts the entire screen. If you plan on pixel based scrolling instead of 8 pixel increments this would also offset your game stats as well.

Does anyone know if having the extra GRAM would cause compatibility issues with prior games? This modification is simple enough to do, and the thought of having double the GRAMs available on stock hardware sounds like a lot of fun to play with.

I just experienced a similar issue, but it was only on one of the games I tried. I used some plastx polish on a qtip and cleaned the tin contacts on the cartridge and it resolved it.

One thing that helped me immensely was developing ways to compress levels down. For Super Mario Bros, fitting 32 stages and all the various secret areas was not going to happen without some kind of compression. The repeating backgrounds are drawn in 1x12 strips that are pulled from a table, and the level objects are drawn over the background as needed, but done with DATA PACKED tables that contain the following: Object type (single backtab tile, tile strip, enemy, warp, etc) Object attribute (tile strip size, warp reference point, etc) Screen X position Screen Y position Two 8 bit values in DATA PACKED are combined into a single 16 bit value. These are decoded back to two separate values by Value / 256 and Value % 256 respectively. I also pack all in game text the same way and try to avoid using PRINT statements all together using a subroutine like this: DISPLAY_TEXT: PROCEDURE FOR I = 0 TO TEXT_LENGTH #BACKTAB(TEXT_POSITION + I * 2) = (GAME_TEXT(I + #TEXT_OFFSET) / 256) * 8 + 7 + #LEVEL_BGCOLOR #BACKTAB(TEXT_POSITION + I * 2 + 1) = (GAME_TEXT(I + #TEXT_OFFSET) % 256) * 8 + 7 + #LEVEL_BGCOLOR NEXT END GAME_TEXT: DATA PACKED "GAME TEXT GOES HERE!" It's certainly not as convenient as using PRINT since you need to keep track of the offset of where to begin reading the text, but it has helped me reduce the footprint of all my game projects. Having a function at the beginning of the program as shown below also helps with more easily using the subroutine: DEF FN DISP_TEXT (A, B, C) = TEXT_POSITION = A: TEXT_LENGTH = B/2: #TEXT_OFFSET = C/2: GOSUB DISPLAY_TEXT

I've had many issues in the past with having bulky code and needing to shrink the footprint some. consider replacing routines like: counter = counter + 1: if counter > 1 then counter = 0 with counter = 1 - counter or counter = counter + 1: if counter > 7 then counter = 0 with counter = (counter + 1) % 8 Those can free a small amount. Everything adds up if you have many routines like that though. Nanochess' example on using DATA routines for tables is incredibly useful. I use tables for just about everything, including movement patterns for enemies, jumping animation, enemy attributes, as well as stage configuration. If you using PRINT commands to place a few GRAMs or characters on screen, it can be leaner to use #BACKTAB instead. DO/LOOP tends to be more wasteful than having a label and a IF THEN GOTO statement. Having subroutines that check enemy backtab collision, updating enemy X or Y position, or changing enemy direction can be useful if you have many different enemy types. Each enemy can call on the same subroutines rather than duplicating the same type of code for each enemy type. I tend to use subroutines for lots of little things as well, like clearing sprites on screen, resetting enemy variables, or time delays (FOR I = 0 to DELAY_TIME: WAIT: NEXT).