43 replies to this topic

[GroovyBee]

My CP1600 assembly language is getting up to speed so here's my 2nd WIP. Its provisionally called Mystery Castle.




As soon as I can test on real hardware and there is more of a game, binaries will be available. There's not much going on besides a moveable, animated, multi-colour player sprite at the moment.

[cmart604]

GroovyBee, on Fri Sep 10, 2010 11:56 AM, said:

My CP1600 assembly language is getting up to speed so here's my 2nd WIP. Its provisionally called Mystery Castle.

shot0000.gif shot0001.gif
shot0002.gif shot0003.gif

As soon as I can test on real hardware and there is more of a game, binaries will be available. There's not much going on besides a moveable, animated, multi-colour player sprite at the moment.

Very cool looking Mark! I can't wait to see your progess on these 2 INTV games.

[iwan-iwanowitsch-goratschin]

HEY, that´s LINK!

[GroovyBee]

cmart604, on Fri Sep 10, 2010 3:29 PM, said:

Very cool looking Mark! I can't wait to see your progess on these 2 INTV games.

Thanks for the compliment. The next steps in the game are to add some collision detection and extend the world beyond the one room. The rooms are put together like lego bricks so there will be quite a bit of variety. Then I can add monsters and shooting. Only then does it start to become a real game .

[GroovyBee]

iwan-iwanowitsch-goratschin, on Fri Sep 10, 2010 3:34 PM, said:

HEY, that´s LINK!

More like PINK! I might make the player's skin orange then it won't look like he's out of breath all the time.

[cmart604]

GroovyBee, on Fri Sep 10, 2010 3:43 PM, said:

cmart604, on Fri Sep 10, 2010 3:29 PM, said:

Very cool looking Mark! I can't wait to see your progess on these 2 INTV games.

Thanks for the compliment. The next steps in the game are to add some collision detection and extend the world beyond the one room. The rooms are put together like lego bricks so there will be quite a bit of variety. Then I can add monsters and shooting. Only then does it start to become a real game .

Must...contain....excitement...

[Jess Ragan]

Looks kind of like the ColecoVision game Alcazar. Was that an inspiration?

[GroovyBee]

Jess Ragan, on Fri Sep 10, 2010 4:29 PM, said:

Looks kind of like the ColecoVision game Alcazar. Was that an inspiration?

Nope! It'll be similar to this game I'm developing on the 7800 :-

http://www.atariage....appy-halloween/

[intvnut]

GroovyBee, on Fri Sep 10, 2010 11:56 AM, said:

shot0000.gif shot0001.gif
shot0002.gif shot0003.gif

As soon as I can test on real hardware and there is more of a game, binaries will be available. There's not much going on besides a moveable, animated, multi-colour player sprite at the moment.

Looks awesome! :-)

GroovyBee, on Fri Sep 10, 2010 11:56 AM, said:

My CP1600 assembly language is getting up to speed so here's my 2nd WIP. Its provisionally called Mystery Castle.

Indeed it does! Since it seems you're no stranger to assembly code, I have to ask: What do you think of the CP-1600 so far?

[GroovyBee]

intvnut, on Fri Sep 10, 2010 6:16 PM, said:

Looks awesome! :-)

Thanks for the compliment.

Quote

What do you think of the CP-1600 so far?

Its interesting. It sort of reminds me of hybrid THUMB/x86/C166/C167. I miss setting condition code register flags on indirect memory moves tho . Got caught out big time on that .

I'm also fighting as1600 quite a lot too. I'm too used to using things like "#~RANDOM_BIT_FLAG, r0" which has to be replaced with "#NOT(RANDOM_BIT_FLAG) AND $FFFF, r0" otherwise the assembler generates an error. The "NOT" I don't mind the "AND $FFFF" feels redundant because the assembler knows the size of the instruction's immediate field and it should just "do the right thing". The syntax of "#'0'-32, r0" isn't valid either . Not having a linker is taking some getting used to as well. Is there a way to switch off listings? I normally do that in included files so they don't clutter the place up. Sorry for all the gripes about the tools you maintain.

[LS_Dracon]

Looks promissing

Quote

More like PINK! I might make the player's skin orange then it won't look like he's out of breath all the time.

Yeah, for me color limit is worse than sprite limit.

[GroovyBee]

LS_Dracon, on Fri Sep 10, 2010 7:29 PM, said:

Looks promissing

Thanks for the compliment.

Quote

Yeah, for me color limit is worse than sprite limit.

You can have 16 colours on screen (with some restrictions) but the colours are just so 70's . You can also have 8 single colour sprites on screen at the same time (with hardware X/Y zoom, X/Y flipping and collision detection). To get the multi-colour player I have to overlay 3 of them.

[revolutionika]

groovybee......if i wasnt already married.....

[cmart604]

revolutionika, on Fri Sep 10, 2010 7:45 PM, said:

groovybee......if i wasnt already married.....

That's just internet gold.

[intvnut]

GroovyBee, on Fri Sep 10, 2010 6:36 PM, said:

intvnut, on Fri Sep 10, 2010 6:16 PM, said:

Looks awesome! :-)

Thanks for the compliment.

Quote

What do you think of the CP-1600 so far?

Its interesting. It sort of reminds me of hybrid THUMB/x86/C166/C167. I miss setting condition code register flags on indirect memory moves tho . Got caught out big time on that .

I'm also fighting as1600 quite a lot too. I'm too used to using things like "#~RANDOM_BIT_FLAG, r0" which has to be replaced with "#NOT(RANDOM_BIT_FLAG) AND $FFFF, r0" otherwise the assembler generates an error. The "NOT" I don't mind the "AND $FFFF" feels redundant because the assembler knows the size of the instruction's immediate field and it should just "do the right thing". The syntax of "#'0'-32, r0" isn't valid either . Not having a linker is taking some getting used to as well. Is there a way to switch off listings? I normally do that in included files so they don't clutter the place up. Sorry for all the gripes about the tools you maintain.

Please let me get you the current build of the tools. They fix the "AND $FFFF" problem. Heck, I think even the jzIntv 1.0 beta3 release has this fixed. That drove me f'ing bonkers also.

As for characters as constants... yeah, that's an artifact of the Frankenstein assembler treating "string" and 'string' as identical. It's rather baked into its parser and I don't know how to get it out easily without breaking a bunch of stuff. ASC('0',0)-32 works, though, and if you want to make it shorter, you can use a macro:

MACRO idx(x)
    ASC('%x%',0)-32
ENDM

You can modulate listings with the LISTING directive. See jzintv/doc/utilities/as1600.txt for details.

[intvnut]

intvnut, on Fri Sep 10, 2010 9:00 PM, said:

As for characters as constants... yeah, that's an artifact of the Frankenstein assembler treating "string" and 'string' as identical. It's rather baked into its parser and I don't know how to get it out easily without breaking a bunch of stuff. ASC('0',0)-32 works, though, and if you want to make it shorter, you can use a macro:

Actually, I'm an idiot. I think I have an idea to make it work. I'll let you know what I come up with.

[GroovyBee]

intvnut, on Fri Sep 10, 2010 9:00 PM, said:

Please let me get you the current build of the tools. They fix the "AND $FFFF" problem. Heck, I think even the jzIntv 1.0 beta3 release has this fixed. That drove me f'ing bonkers also.

That's the version I'm using.

Quote

As for characters as constants... yeah, that's an artifact of the Frankenstein assembler treating "string" and 'string' as identical. It's rather baked into its parser and I don't know how to get it out easily without breaking a bunch of stuff. ASC('0',0)-32 works, though, and if you want to make it shorter, you can use a macro:

MACRO idx(x)
    ASC('%x%',0)-32
ENDM

Thanks for that. I'll go back and adjust my code so its readable again.

Quote

You can modulate listings with the LISTING directive. See jzintv/doc/utilities/as1600.txt for details.

I thought the answer would be in the documentation some place. I did look but I was more interested in ploughing on with the game.

[GroovyBee]

revolutionika, on Fri Sep 10, 2010 7:45 PM, said:

groovybee......if i wasnt already married.....

We have incompatible connector ports so it'll never work .

[GroovyBee]

GroovyBee, on Sat Sep 11, 2010 3:14 AM, said:

That's the version I'm using.

My mistake, I was using the one in SDK-1600, I've switched over to the jzintv one now.

[GroovyBee]

What's new in the latest version?

- 4 room styles
- 15 rooms to explore
- Collision detection with walls




And... the ROM (you might need to rename it back to *.rom because I can't upload *.rom files to the forum).

 castle_14_09_10.1.02.rom.bin   5.06K   94 downloads

I haven't tested this version on real hardware so apologies in advance to the CC3 owners if it doesn't work correctly. However it works fine on jzintv and Bliss.

As always, comments and suggestions welcome.

[catsfolly]

I got 0 points! Has anyone beaten that yet?

So far so good! The screens look good and the transitions are smooth and quick.

The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors.

Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought.

The seems to be a tall stack of green plates on the right edge of the display - what's the deal with that?

Looks promising!! Thanks for letting us try it out!

[GroovyBee]

catsfolly, on Wed Sep 15, 2010 7:49 AM, said:

I got 0 points! Has anyone beaten that yet?

There isn't much to do in the game at the moment.

Quote

So far so good! The screens look good and the transitions are smooth and quick.

Have you tested it using a CC3?

Quote

The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors.

I've implemented sliding so you can hold a diagonal direction and you'll move along the wall and then nip through the door. You don't have to be pixel perfect. When beasties start chasing you, sliding will come in very handy .

Quote

Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought.

The player speed seemed too slow to me. I'll experiment when I get some time.

Quote

The seems to be a tall stack of green plates on the right edge of the display - what's the deal with that?

That's the player's energy bar. Most things are provisional at the moment, so I might replace it with the word "ENERGY" on a green background. One of the problems is that the Inty doesn't have a wide range of colours to choose from. Its also a trade off between available tile/sprite bitmaps (in that you can only have 64) and having more interesting items in the rooms.

Quote

Looks promising!! Thanks for letting us try it out!

Thanks for the compliment. The game will get better . Its only my 2nd week of Inty coding .

[intvnut]

GroovyBee, on Wed Sep 15, 2010 8:07 AM, said:

catsfolly, on Wed Sep 15, 2010 7:49 AM, said:

So far so good! The screens look good and the transitions are smooth and quick.

Have you tested it using a CC3?

I have and it worked just fine. The thin green vertical lines show up a little weak, though, on my LCD CRT. Dunno if it's just the TV or possibly an artifact of the STIC's NTSC output.

(Aside: I did have to change the ROM to CC3 format to download it via serial. The two formats are identical save for the first byte, because they (annoyingly) use different autobaud schemes. "as1600 -c" will output the CC3 autobaud byte in the header. Otherwise it's trivial to change in a hex editor. First byte is 0xA8 for Intellicart, 0x41 for CC3. Or, you can use "rom_merge --cc3 foo.rom bar.rom". I forget which format .ROM Chad expects on the MicroSD and which format Chad's GUI front end expects. I vaguely recall that one or both want the Intellicart autobaud byte, but I can't remember for sure. Anyway, my tools make it easy to convert between to two.)

GroovyBee, on Wed Sep 15, 2010 8:07 AM, said:

catsfolly, on Wed Sep 15, 2010 7:49 AM, said:

The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors.

I've implemented sliding so you can hold a diagonal direction and you'll move along the wall and then nip through the door. You don't have to be pixel perfect. When beasties start chasing you, sliding will come in very handy .

Quote

Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought.

The player speed seemed too slow to me. I'll experiment when I get some time.

Vertical seemed fine to me, or maybe even a tad slow, but horizontally the character really hauls a**. I figured you might be trying make the transit time horizontally across the screen similar to vertically or something. It does seem asymmetric. Or was I imagining things?

GroovyBee, on Wed Sep 15, 2010 8:07 AM, said:

catsfolly, on Wed Sep 15, 2010 7:49 AM, said:

Looks promising!! Thanks for letting us try it out!

Thanks for the compliment. The game will get better . Its only my 2nd week of Inty coding .

Allow me to throw a "me too" in there: I too think it looks promising!

[GroovyBee]

intvnut, on Wed Sep 15, 2010 8:42 AM, said:

I have and it worked just fine. The thin green vertical lines show up a little weak, though, on my LCD CRT. Dunno if it's just the TV or possibly an artifact of the STIC's NTSC output.

Thanks for testing. The vertical lines are only a pixel wide. I'll see how they look on my PAL TV when I get my CC3. Maybe the shade of green isn't optimum. The rooms will be different colours in the final game just to add a bit of extra variety.

Quote

(Aside: I did have to change the ROM to CC3 format to download it via serial. The two formats are identical save for the first byte,

Points noted about the CC3 format. I'll add both in the next release.

Quote

Vertical seemed fine to me, or maybe even a tad slow, but horizontally the character really hauls a**. I figured you might be trying make the transit time horizontally across the screen similar to vertically or something. It does seem asymmetric. Or was I imagining things?

Its moving two pixels in X at the moment. I'll have a play with frame delay and X step in the next version.

Quote

Allow me to throw a "me too" in there: I too think it looks promising!

I'm glad people like it. The next version will have much more of the real game in place.

[intvnut]

GroovyBee, on Wed Sep 15, 2010 8:55 AM, said:

intvnut, on Wed Sep 15, 2010 8:42 AM, said:

Vertical seemed fine to me, or maybe even a tad slow, but horizontally the character really hauls a**. I figured you might be trying make the transit time horizontally across the screen similar to vertically or something. It does seem asymmetric. Or was I imagining things?

Its moving two pixels in X at the moment. I'll have a play with frame delay and X step in the next version.

One trick I used in Space Patrol was to use a rotated 1s complement representation for X/Y position and X/Y velocity. By rotated, I mean the fractional portion was in the MSB and the integer portion was in the LSB. Velocity and position are both 8.8 values, allowing a wide range of velocity control. To add velocity to position, I do:

        ; assume velocity in R0, position in R1
        ADDR    R0,     R1     ; seemingly normal 2s complement ADD
        ADCR    R1             ; end-around carry for 1s complement

The reason I used a rotated format like this is twofold. The first is that when I go to merge X/Y into the MOB registers, I can just do:

        ; assume rotated X is in R0, other X-register bits in R1
        ANDI    #$FF,   R0
        ADDR    R0,     R1

The second is that I can do "SIMD" bounding box checks for collisions. The SDBD prefix tells the CPU to read the LSBs of two bytes. When used with an incrementing pointer, it's a handy way to read X and Y packed into a single register, provided the X and Y positions are in the LSB.

        ; assume R4 points to X, and that X/Y stored adjacently
        SDBD
        MVI@    R4,     R0    ; LSB holds X, MSB holds Y

Now with the packed X/Y, I can do a single subtract to see if the X/Y for the one object is greater than the X/Y for another. Here's a code excerpt from Space Patrol. In this excerpt, "GGB1" holds the already-packed Y/X upper-left coordinate of my bullet, and R4 points to the X/Y positions of a bad guy, and R3 points to a packed representation of the bad-guy's size, biased by the size of the bullet:

        SDBD                          
        MVI@    R4,     R1      ;   8  Get Y/X coordinate of bad guy
                                      
        MOVR    R1,     R2      ;   6  save it for comparing against the next bullet (GGB2)
                                      
        SUB     GGB1,   R1      ;  10  Check the lower right corner
        BNC     @@out1          ; 7/9  If Y went -ve, bullet's to the right
        SWAP    R1,     1       ;   6  
        SWAP    R1,     1       ;   6  
        BMI     @@out1          ; 7/9  If X went -ve, bullet's below

        ;;------------------------------------------------------------------;;
        ;;  At this point R1 contains our X distance to the right,          ;;
        ;;  and our Y distance to the right of the bullet's upper left      ;;
        ;;  corner vs. the lower right corner of the bad guy.  So, if       ;;
        ;;  we subtract the bad buy's width and we still end up positive,   ;;
        ;;  we're to the left or above.  (Note that we bias all bad-guy     ;;
        ;;  widths in our table by the width/height of the bullet.)         ;;
        ;;------------------------------------------------------------------;;
        SUB@    R3,     R1      ;   8  Compare to bad-guy's size.
        BPL     @@out1          ; 7/9  If Y still +ve, bullet's to the left
        SWAP    R1,     2       ;   8
        BPL     @@out1          ; 7/9  If X still +ve, bullet's above

        ;;------------------------------------------------------------------;;
        ;;  If we made it this far, it's a HIT.                             ;;
        ;;  Disable bullet 1 and then process the hit.                      ;;
        ;;------------------------------------------------------------------;;
        CLRR    R1              ;   6
        MVO     R1,     SPAT2+5 ;  11  disable the good-guy bullet #1

        B       @@hit           ;   9

In SP, since I have 3 active tank bullets and 12 things they can hit, anything I can save on the bounding box compare is huge.

The complete function is here: http://spacepatrol.i...ngine/ckggb.asm

Edited by intvnut, Wed Sep 15, 2010 9:38 AM.