[Dragon Quest...ions]

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.

 

 

 

[Dragon Quest...ions]

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.

 

 

[IntyBASIC for Amiga computers]

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.

[IntyBASIC for Amiga computers]

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

[IntyBASIC for Amiga computers]

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)

[Contra]

14 minutes ago, ALEXANDER said:

One question what emulator do you use for loading bin files to play your game ? Thanks in advance.

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

 

[Contra]

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.

 

 

[Contra]

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

[Contra]

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.

[Contra]

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

[Dragon Quest]

4 hours ago, Sinjinhawke said:

Such a weird coincidence that the next day after playing your conversion Youtube recommends a video of another conversion of this game but to the Turbografx 16.  Having never played the original NES version it was nice to see this and get a feel for how accurate your conversion is.  Really excellent work.

 

 

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.

 

 

 

[Dragon Quest]

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.

[Dragon Quest]

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

 

[Dragon Quest]

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. 

[Scroll Left to right issue]

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?

[Scroll Left to right issue]

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

 

 

[Scroll Left to right issue]

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.

[Scroll Left to right issue]

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

 

 

[Scroll Left to right issue]

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.

 

 

 

[More scrolling issues]

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.

[More scrolling issues]

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.

[Expanded GRAM]

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.

[Microvision replacement screen project - pre-order & purchase here]

15 minutes ago, nickle241 said:

so im actually having a seperate issue, the dial seems unreliable and ive already cleaned it, would one of the capacitors failing cause the dial to become unresponsive? it basically shoots off to one side, usually the left and stays stuck there as far as the display allows, since its sporadic and not part of the dial travel im suspecting either contact issues with the cartrtidge or the caps

not really sure if this is the place to ask, but i dont have many other places i know where people might know

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.  

[Managing ROM size with efficient code.]

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

 

[Managing ROM size with efficient code.]

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