Devil Slayer - Legacy of the Feline

[Alp]

This contest brought me over here from Twitter, so I'll make the thread over here.

I'm an artist for CollectorVision, so I will NOT be entering the contest.

 

I will make a game for this event, however! I need to brush up on BASIC.

 

From what I've read, the restrictions of the Intellivision appear to be very similar to the MSX computer.

Anybody who's played Knightmare II (Maze of Galious) will know what to expect from this!

[pimpmaul69]

This contest brought me over here from Twitter, so I'll make the thread over here.

I'm an artist for CollectorVision, so I will NOT be entering the contest.

 

I will make a game for this event, however! I need to brush up on BASIC.

 

From what I've read, the restrictions of the Intellivision appear to be very similar to the MSX computer.

Anybody who's played Knightmare II (Maze of Galious) will know what to expect from this!

looks really good. Cant wait.

[Kiwi]

That look really good!! It'll work fine in colorstack mode. However, BG/FG mode restriction requires the first 8 colors for FG pixel, and can use the 16 colors for the BG pixel. In BG/FG mode, it lose the ability to use lower case letters, and the colored squares cards.

[+nanochess]

I'm loving the look

[+cmart604]

Wow! That looks very cool ?

[SiLic0ne t0aD]

Impressive!

[artrag]

Maze of Galious for Intellivsion would be awesome!

Very nice graphics.

PS

There are some similarities between intellivision and msx graphic but I find a true pain the limit of 64 tiles for background and sprites and the limit of 8 sprites on the screen (not reusable with line interrupts or similar trick).

 

The plus are hw scrolling and zooming effects selectable on each sprites.

Edited October 21, 2015 by artrag

[GroovyBee]

This contest brought me over here from Twitter, so I'll make the thread over here.

I'm an artist for CollectorVision, so I will NOT be entering the contest.

The only people that can't enter the contest are the judges. I don't see a conflict of interest, so feel free to submit your game as an official entry.

 

From what I've read, the restrictions of the Intellivision appear to be very similar to the MSX computer.

Anybody who's played Knightmare II (Maze of Galious) will know what to expect from this!

Looks good. If you have any IntyBASIC questions or problems just ask here or in the Intellivision Programming section. From your tile graphics if you arrange them in the following order :-

 

left head, shield/feet, right head, sword/feet

 

You can take advantage of double height sprites so the main character will then only take 2 of the 8.

[Alp]

The only people that can't enter the contest are the judges. I don't see a conflict of interest, so feel free to submit your game as an official entry.

 

 

Looks good. If you have any IntyBASIC questions or problems just ask here or in the Intellivision Programming section. From your tile graphics if you arrange them in the following order :-

 

left head, shield/feet, right head, sword/feet

 

You can take advantage of double height sprites so the main character will then only take 2 of the 8.

Conflict of interest, is precisely why I'm not comfortable making my entry "official".

I started this thread, so as to not annoy Jean with my stupid questions!

I figured asking the community if I need help, would be less annoying for him.

 

Oh! I was wondering how 8x16 sprites worked on this. Just like on the NES! Good to know. Thanks for the info!

So wait, sprites in 8x16 format, can actually be used alongside 8x8 sprites?! What wizardry is this? The NES can't even do that!

Maze of Galious for Intellivsion would be awesome!

Very nice graphics.

PS

There are some similarities between intellivision and msx graphic but I find a true pain the limit of 64 tiles for background and sprites and the limit of 8 sprites on the screen (not reusable with line interrupts or similar trick).

 

The plus are hw scrolling and zooming effects selectable on each sprites.

Thanks! Maze of Galious is an inspiration to many of the games I design.

 

The 64 tile limit isn't too bad, only 1/4 of what the NES can do. Which I've made entire games in! (Super Mario Bros. 1 limitation.)

The 8 sprite limit will no doubt, be trickier though!

 

From reading around, it seems that you can swap in new tiles from PRG to the GRAM, for things like a title screen/alternate tiles?

If this is the case, is it safe to assume that you only need to store 1 copy of a given asset, as opposed to copied sprites/tiles across multiple tilesets? (juxtaposition) The information doesn't make that part clear.

That look really good!! It'll work fine in colorstack mode. However, BG/FG mode restriction requires the first 8 colors for FG pixel, and can use the 16 colors for the BG pixel. In BG/FG mode, it lose the ability to use lower case letters, and the colored squares cards.

I'm actually not 100% clear on how those modes work, so I approximated, based on the MSX, and games I've seen on the Intellivision.

It restricts to the first... 64 characters in GROM, correct? The loss of lower-case wouldn't be a problem at all.

 

I'll need to experiment with those, to really figure out the particulars of how they behave.

[GroovyBee]

Conflict of interest, is precisely why I'm not comfortable making my entry "official".

If the contest was restricted to people that the judges didn't know, then there wouldn't be any entries .

 

I started this thread, so as to not annoy Jean with my stupid questions!

I figured asking the community if I need help, would be less annoying for him.

You get all kinds of replies in open threads .

 

Oh! I was wondering how 8x16 sprites worked on this. Just like on the NES! Good to know. Thanks for the info!

So wait, sprites in 8x16 format, can actually be used alongside 8x8 sprites?! What wizardry is this? The NES can't even do that!

Thanks! Maze of Galious is an inspiration to many of the games I design.

Yep! There are 2 magnification levels in X and 3 magnification levels in Y, along with X and Y flipping.

 

The 64 tile limit isn't too bad, only 1/4 of what the NES can do. Which I've made entire games in! (Super Mario Bros. 1 limitation.)

The 8 sprite limit will no doubt, be trickier though!

There are interesting "bloxel" tiles in colour stack accessible GROM. These can be used in title pages and the like to reduce the number of GRAM tiles needed.

 

From reading around, it seems that you can swap in new tiles from PRG to the GRAM, for things like a title screen/alternate tiles?

If this is the case, is it safe to assume that you only need to store 1 copy of a given asset, as opposed to copied sprites/tiles across multiple tilesets? (juxtaposition) The information doesn't make that part clear.

I'm actually not 100% clear on how those modes work, so I approximated, based on the MSX, and games I've seen on the Intellivision.

It restricts to the first... 64 characters in GROM, correct? The loss of lower-case wouldn't be a problem at all.

Correct! In IntyBASIC you can reprogram 16 tiles per vertical blank period (18 without in-game music). So if you blanked the screen for 2 frames between rooms you could reload 32 tiles. Check out my AA profile for the kinds of title pages you can do in colour stack mode.

 

I'll need to experiment with those, to really figure out the particulars of how they behave.

Are you usings the IntyBASIC SDK? If so, check out :-

 

..\IntyBASIC SDK\Documents\Tech\stic.txt

 

For the low down on the Inty video chip called Standard Television Interface Chip or STIC for short.

[Alp]

If the contest was restricted to people that the judges didn't know, then there wouldn't be any entries .

 

 

You get all kinds of replies in open threads .

 

 

Yep! There are 2 magnification levels in X and 3 magnification levels in Y, along with X and Y flipping.

 

 

There are interesting "bloxel" tiles in colour stack accessible GROM. These can be used in title pages and the like to reduce the number of GRAM tiles needed.

 

 

Correct! In IntyBASIC you can reprogram 16 tiles per vertical blank period (18 without in-game music). So if you blanked the screen for 2 frames between rooms you could reload 32 tiles. Check out my AA profile for the kinds of title pages you can do in colour stack mode.

 

 

Are you usings the IntyBASIC SDK? If so, check out :-

 

..\IntyBASIC SDK\Documents\Tech\stic.txt

 

For the low down on the Inty video chip called Standard Television Interface Chip or STIC for short.

Uh... I'll consider making an official entry. Possibly. The idea still makes me uncomfortable.

 

I noticed the magnification levels, I assume vertical arcade shooters were common early on? Just from the default, squished sprites.

 

So if I really wanted, I could be crazy and go all out with multiple minimal tilesets! Like this:

(I may switch Mr. Spider to an up-scaled 8x8, to make room for ground crawling frames.)

The player will be 2 sprites, with a reserved sprite for weapons. (Sword, Arrows)

 

I am indeed using the SDK!

...are you kidding me?! I was stumbling through the manual, one sub-file away from the technical information? ...Crap.

[GroovyBee]

Uh... I'll consider making an official entry. Possibly. The idea still makes me uncomfortable.

It was just a thought.

 

So if I really wanted, I could be crazy and go all out with multiple minimal tilesets! Like this:

(I may switch Mr. Spider to an up-scaled 8x8, to make room for ground crawling frames.)

The player will be 2 sprites, with a reserved sprite for weapons. (Sword, Arrows)

Yep! Just load the "theme" for each screen. With such colourful screens it might look a bit odd if the background shows through your avatar's shield so you might want to use a black sprite to mask that out.

 

I am indeed using the SDK!

...are you kidding me?! I was stumbling through the manual, one sub-file away from the technical information? ...Crap.

There are plenty of other technical information docs in that folder too. Make sure you are using "constants.bas" in your source code. It has lots of handy constants (as its name implies) so you don't have to remember a bunch of "magic numbers" when dealing with STIC and the controllers.

[artrag]

Uh... I'll consider making an official entry. Possibly. The idea still makes me uncomfortable.

 

I noticed the magnification levels, I assume vertical arcade shooters were common early on? Just from the default, squished sprites.

 

So if I really wanted, I could be crazy and go all out with multiple minimal tilesets! Like this:

(I may switch Mr. Spider to an up-scaled 8x8, to make room for ground crawling frames.)

The player will be 2 sprites, with a reserved sprite for weapons. (Sword, Arrows)

 

I am indeed using the SDK!

...are you kidding me?! I was stumbling through the manual, one sub-file away from the technical information? ...Crap.

Consider that you could update on fly the tiles used by the main character reserving in gram only two tiles for its definition.

The same holds for simpler enemies whose animation can go synchronised. E.g. slimes or other front facing creatures. If you want side views you can use one tile as well and use the flip and mirror bits on enemies going in the opposite direction.

Edited October 21, 2015 by artrag

[+nanochess]

Consider that you could update on fly the tiles used by the main character reserving in gram only two tiles for its definition.

The same holds for simpler enemies whose animation can go synchronised. E.g. slimes or other front facing creatures. If you want side views you can use one tile as well and use the flip and mirror bits on enemies going in the opposite direction.

 

Given most games update animation at 30 frames per second, you can update four independent GRAM zones using something like this:

DEFINE 0,4,VARPTR sprites_player(player_frame * 16)  ' Supposing you have a player animation
DEFINE ALTERNATE 4,4,VARPTR sprites_fire(fire_frame * 16)  ' Supposing you have a fire animation
WAIT
DEFINE 8,4,VARPTR sprites_enemies(enemy_frame * 16) ' Supposing you have an enemy animation
DEFINE ALTERNATE 12,1,VARPTR sprites_shot(shot * 4) ' Supposing you have different shots
WAIT

Just some ideas

[Alp]

After almost 4 hours of banging my head against the wall, and cross-referencing 3 different sources--

It turns out that I was spot-on. I simply forget the "$" symbol to specify hexadecimal. Oops!

 

The HUD is already separated into its' own drawing subroutine. It doesn't draw the Life or Exp values, yet.

Now... Just to add the game!

 

Given most games update animation at 30 frames per second, you can update four independent GRAM zones using something like this:

DEFINE 0,4,VARPTR sprites_player(player_frame * 16)  ' Supposing you have a player animation
DEFINE ALTERNATE 4,4,VARPTR sprites_fire(fire_frame * 16)  ' Supposing you have a fire animation
WAIT
DEFINE 8,4,VARPTR sprites_enemies(enemy_frame * 16) ' Supposing you have an enemy animation
DEFINE ALTERNATE 12,1,VARPTR sprites_shot(shot * 4) ' Supposing you have different shots
WAIT

Just some ideas

That makes sense! Would it be possible to update 5, small GRAM sections, of variable use? (Not all monster slots, are always "active")

 

4-tile <dynamic> Player

12-tile <fixed> Weapons / Effects / Items

4, 4-tile <dynamic> Monsters, of variable tile Size / Use

32-tiles <reserved> for Background Data.

 

Something that looks like this:

[GroovyBee]

That makes sense! Would it be possible to update 5, small GRAM sections, of variable use? (Not all monster slots, are always "active")

 

4-tile <dynamic> Player

12-tile <fixed> Weapons / Effects / Items

4, 4-tile <dynamic> Monsters, of variable tile Size / Use

32-tiles <reserved> for Background Data.

Sure! If the screen contains all 4 enemies then you'd have to reprogram tiles on alternates frames e.g.

 

Frame 0 - Player

Frame 1 - All 4 enemies

Frame 2 - Player

Frame 3 - All 4 enemies

...

 

Thats not such a burden because the animation frames for the player's avatar and the NPCs do not need to change on every frame.

[Alp]

Sure! If the screen contains all 4 enemies then you'd have to reprogram tiles on alternates frames e.g.

 

Frame 0 - Player

Frame 1 - All 4 enemies

Frame 2 - Player

Frame 3 - All 4 enemies

...

 

Thats not such a burden because the animation frames for the player's avatar and the NPCs do not need to change on every frame.

Oh! Frame delays, I hadn't thought of that.

Okay, I have the game engine's basic framework laid out. I just need to fill out the code for it.

 

I worked on some new tiles, and mocked up different game locales:

That title card is exactly 16 tiles, I'm not sure if I'll keep it.

I'm trying to recycle tiles, where I can, to potentially make the game larger.

I have yet to attempt drawing the town tiles.

 

Here is the progress on sprites.

I have most of these converted into data already, with basic pointers to each frame.

That "Roper" monster flips it's frames horizontally, to produce a smooth 4-frame animation.

 

I have a technical question. As this is an action oriented game, requiring 2 buttons, 1 for jumping and another for attacking--

Which buttons do I use for this? I've never programmed on this console before. So I don't know what the "standard" is. If any.

 

A 3rd button would be nice for the sub-menu. But isn't required.

[GroovyBee]

I have a technical question. As this is an action oriented game, requiring 2 buttons, 1 for jumping and another for attacking--

Which buttons do I use for this? I've never programmed on this console before. So I don't know what the "standard" is. If any.

Do you fire more times than you jump or jump more times than you fire? Whichever avatar fire/jump action you do the most I'd suggest putting it on the top buttons (left and right top button are the "same" button). Put the 2nd most used action on the bottom buttons. The bottom buttons are separate but ideally you want to make it easier for lefties too.

 

A 3rd button would be nice for the sub-menu. But isn't required.

Personally I wouldn't waste a button on it, I'd put it in the "game paused" screen. Normally if keypad keys '1' and '9' are down together the game enters pause. What you display on the "pause" screen is up to you.

[Alp]

Do you fire more times than you jump or jump more times than you fire? Whichever avatar fire/jump action you do the most I'd suggest putting it on the top buttons (left and right top button are the "same" button). Put the 2nd most used action on the bottom buttons. The bottom buttons are separate but ideally you want to make it easier for lefties too.

 

 

Personally I wouldn't waste a button on it, I'd put it in the "game paused" screen. Normally if keypad keys '1' and '9' are down together the game enters pause. What you display on the "pause" screen is up to you.

Jumping will probably take priority, then. Enemies are a second, when it comes to exploring.

Using sub-weapons doesn't take an extra button, just down+attack.

 

Pausing is what I was referring to, as the sub-screen. Just to pause, and look at your items/map.

Is 1+9 how people usually program pausing? That's odd, considering the button placement.

 

My initial mock-up lives!

I built a tile-chart for the tile values. One at a time. It made building the map screen, much faster!

 

The alignment was kind of dumb. I'll look into converting the map data into metatiles, in the future.

[GroovyBee]

Is 1+9 how people usually program pausing? That's odd, considering the button placement.

Thats the just the way it is . You could implement your own key combination or pause strategy.

 

My initial mock-up lives!

 

 

 

 

I built a tile-chart for the tile values. One at a time. It made building the map screen, much faster!

 

The alignment was kind of dumb. I'll look into converting the map data into metatiles, in the future.

Have you thought about using TileStudio? I've used it for all of my map based projects. It has its quirks but you can get going quite quickly with it. It has its own scripting language so it should be possible to output IntyBASIC friendly files. I use its custom scripting language to create source code for my assembly language projects.

[+DZ-Jay]

 

Pausing is what I was referring to, as the sub-screen. Just to pause, and look at your items/map.

Is 1+9 how people usually program pausing? That's odd, considering the button placement.

 

 

For that sort of thing, I wouldn't recommend implementing it as 1+9. I recommend assigning a specific key on the keypad for that function.

 

The 1+9 combo was built into the EXEC of the Intellivision as a means to actually "pause" the game -- the screen goes blank and the execution loops in place until another key is pressed. It was considered that since there is no overlap between the signals for the keys 1 and 9, and they are unambiguous, the combination would be a convenient way of implementing a feature that all games could use, without the chance of clashing with an actual game function.

 

Although home-brews eschew the EXEC, some continue to implement the 1+9 pause feature because it's sort of traditional and convenient.

 

What you are describing is not a "pause" screen, but an actual integral part of the game. The common way of implementing this on the Intellivision is to assign a specific key on the pad for it (and label it on the overlay). If this is the only key function of your game, then something convenient like the "5" key (which is on the very center of the pad) could do. Or "0", which is the directly below on the bottom-row key.

 

For reference, the keypad layout is as follows:

 ,-----.
 |1 2 3|
 |4 5 6|
 |7 8 9|
 |C 0 E|
 `-----'
  ^   ^
  |   |
  |   `--- Enter
  `------- Clear

Edited October 24, 2015 by DZ-Jay

[Alp]

Thats the just the way it is . You could implement your own key combination or pause strategy.

Have you thought about using TileStudio? I've used it for all of my map based projects. It has its quirks but you can get going quite quickly with it. It has its own scripting language so it should be possible to output IntyBASIC friendly files. I use its custom scripting language to create source code for my assembly language projects.

Eh... I'm not into TileStudio. I don't like the way it clumps up imported tiles, into a rigid row.

 

I'll probably figure out an appropriate pausing method, then.

 

 

 

For that sort of thing, I wouldn't recommend implementing it as 1+9. I recommend assigning a specific key on the keypad for that function.

 

The 1+9 combo was built into the EXEC of the Intellivision as a means to actually "pause" the game -- the screen goes blank and the execution loops in place until another key is pressed. It was considered that since there is no overlap between the signals for the keys 1 and 9, and they are unambiguous, the combination would be a convenient way of implementing a feature that all games could use, without the chance of clashing with an actual game function.

 

Although home-brews eschew the EXEC, some continue to implement the 1+9 pause feature because it's sort of traditional and convenient.

 

What you are describing is not a "pause" screen, but an actual integral part of the game. The common way of implementing this on the Intellivision is to assign a specific key on the pad for it (and label it on the overlay). If this is the only key function of your game, then something convenient like the "5" key (which is on the very center of the pad) could do. Or "0", which is the directly below on the bottom-row key.

 

For reference, the keypad layout is as follows:

 ,-----.
 |1 2 3|
 |4 5 6|
 |7 8 9|
 |C 0 E|
 `-----'
  ^   ^
  |   |
  |   `--- Enter
  `------- Clear

Oh! So it *was* a built-in hardware function. I didn't want to sound stupid by asking, in my last post!

 

Hmm... 0 is a nice option. It's out of the way.

 

Ah, Geez! I was building metatile entries for the dungeon tileset, and the savings are absurd! (75%)

The first map screen, shown above, compresses into this:

I'm not sure exactly how to go about implementing metatiles in BASIC.

I've done it in 6502 ASM though, so at least I have a general idea of what I'm doing.

[+DZ-Jay]

What do you mean by "metatiles"?

[Alp]

What do you mean by "metatiles"?

Compression.

 

Pre-built 2x2 tiles, to cut down on the overall size of stored screen data. The result is data that is 25% of it's original size.

The game engine reads each tile as an index, and uses a pointer to write the data to the background.

 

An example:

metatile_05:
DATA $2916,$290E,$290E,$2916

In this case, given the 16-bit nature of the tile data. The result is 60 byte screens (no RLE), rather than the expected 480(?) bytes.

This, combined with a shared metatile set of (currently) only 160 bytes, reduces the data size exponentially.

 

I'm going to focus on developing the game engine for now. I'll work on this aspect of the design, later.

[GroovyBee]

If you are using meta tiles for level compaction then you'll probably want to access #BACKTAB directly for collision detection purposes.