Devil Slayer - Legacy of the Feline

[+DZ-Jay]

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.

 

I guess I never found the need to cut down on the size of tile data. There's plenty of ROM space on the Intellivision platform, and I rather not have to spend too much CPU time on decoding it, which is the bottleneck.

 

You have a buffer in Graphics RAM (GRAM) of 64 cards. Each of your screens do not seem to use as much. You can load each screen from different tile sets when needed. For sprites, you can get away with dynamically loading cards as needed throughout their animation lifecyle, which allows you to use more GRAM for background details.

 

Good luck.

 

-dZ.

[freewheel]

Yeah. The bottleneck is how many tiles you can have loaded into GRAM at once (64). You have virtually unlimited space for actual tile storage though. TONS of ROM space. People have mocked up demo videos and such with a lot of frames of animation - so long as you cycle them in and out of memory fast enough, you can cram a heck of a lot on a cart.

[Kiwi]

I don't think meta-tiles isn't really necessary. You do have 5000-6FFF 16-bit memory map. You can use "asm org $c100" to map data to "c100-FFFF". http://wiki.intellivision.us/index.php?title=Cart.mac have memory map on where you can place data. You can use 42K(84KBytes) word of data without bankswitch. I wouldn't worry too much about tilemap compression, unless it's a huge long game.

 

If you were developing for MSX or Colecovision platform and don't know how to make a mega-cart like me. Then metamapping with pletter compression would do the trick. I crammed unique 57 maps for Rock Cutter.

I am doing line of data compression like Zelda 2 does for my Intellivision shump, Area Fighter, for no reason other than the usual habit I have for the Colecovision. The first 4 tiles repeats until the 16-bit #leveldata tells it to advance to the next group of tiles.

Edited October 26, 2015 by Kiwi

[Alp]

 

I guess I never found the need to cut down on the size of tile data. There's plenty of ROM space on the Intellivision platform, and I rather not have to spend too much CPU time on decoding it, which is the bottleneck.

 

You have a buffer in Graphics RAM (GRAM) of 64 cards. Each of your screens do not seem to use as much. You can load each screen from different tile sets when needed. For sprites, you can get away with dynamically loading cards as needed throughout their animation lifecyle, which allows you to use more GRAM for background details.

 

Good luck.

 

-dZ.

Well, I'm a programmer who just optimizes the crap out of my code as I go along, It's a force of habit.

I'm a former software engineer, after all!

 

I'm only encoding the map screens, the tiles are stored uncompressed. It's a simple matter of writing the data directly to the BACKTAB. It shouldn't be a problem, as the game doesn't scroll, and the screen data is fixed-length (60 bytes). So loading will be consistent.

Yeah. The bottleneck is how many tiles you can have loaded into GRAM at once (64). You have virtually unlimited space for actual tile storage though. TONS of ROM space. People have mocked up demo videos and such with a lot of frames of animation - so long as you cycle them in and out of memory fast enough, you can cram a heck of a lot on a cart.

The tilesets/graphics aren't the problem. It's the size of the actual screen/background data, that is.

 

I don't think meta-tiles isn't really necessary. You do have 5000-6FFF 16-bit memory map. You can use "asm org $c100" to map data to "c100-FFFF". http://wiki.intellivision.us/index.php?title=Cart.mac have memory map on where you can place data. You can use 42K(84KBytes) word of data without bankswitch. I wouldn't worry too much about tilemap compression, unless it's a huge long game.

 

If you were developing for MSX or Colecovision platform and don't know how to make a mega-cart like me. Then metamapping with pletter compression would do the trick. I crammed unique 57 maps for Rock Cutter.

 

I am doing line of data compression like Zelda 2 does for my Intellivision shump, Area Fighter, for no reason other than the usual habit I have for the Colecovision. The first 4 tiles repeats until the 16-bit #leveldata tells it to advance to the next group of tiles.

I want this game to be rather large, as the Overworld will consist of Forests, Mountains, a Desert, an Ocean, and a an Island.

All filled with caves, and Entrances to a number Dungeons.

 

The metatiles are just insurance to prevent having to implement something stupid, later on.

Plus, it makes programming the map screens by hand, more convenient.

 

This game's inspiration, The Maze of Galious, has 156 screens on the "Overworld", and 174 in the Dungeons.

This would amount to 74880, and 83520 bytes on the Intellivision, in it's raw format. Which is insane.

 

If my game goes anywhere near that big, without data-encoding, it would be impossible to manage on this system.

With basic metatiles, that same data would only amount to 9360, and 10440 bytes, respectively.

 

 

 

The short answer is--

This is an adventure game, where you explore a vast world, filled with dungeons. It's going to need unconventional storage methods.

Think Zelda 1, but a platformer.

[+DZ-Jay]

Well, I'm a programmer who just optimizes the crap out of my code as I go along, It's a force of habit.

I'm a former software engineer, after all!

Fair enough.

 

The tilesets/graphics aren't the problem. It's the size of the actual screen/background data, that is.

 

I say, most of the time neither are problems.

 

I want this game to be rather large, as the Overworld will consist of Forests, Mountains, a Desert, an Ocean, and a an Island.

All filled with caves, and Entrances to a number Dungeons.

 

It seems hard to convey that the space limitations of other platforms do not present themselves -- or at least not in the same significant way -- on the Intellivision. The Intellivision does have plenty of room, but it does have its limit.

 

The metatiles are just insurance to prevent having to implement something stupid, later on.

Plus, it makes programming the map screens by hand, more convenient.

 

That's a fair concern. Of course, if you are more comfortable implementing it that way, and it makes it easier, then that's the way to go. Besides, that might be easier than figuring out the intricacies of bank-switching.

 

This game's inspiration, The Maze of Galious, has 156 screens on the "Overworld", and 174 in the Dungeons.

This would amount to 74880, and 83520 bytes on the Intellivision, in it's raw format. Which is insane.

(156 overworld + 174 dungeons) x 240 cells = 79,200 DECLEs in total (BACKTAB words are 16-bit wide). That is considering a full BACKTAB map for each screen. If you reserve the top row for a HUD (which you seem to have done), then that's 6.6K DECLEs less: 72,600 DECLEs

 

Without bank-switching, you can get away with about 42K DECLEs of ROM. Raw, uncompressed storage will require two banks of the available 16.

 

Yes, that is indeed quite a bit -- IF you intend to make the game that large, and IF every screen is indeed unique (I am not familiar with The Maze of Galious). Then of course, you'll need some sort of compression or bank-switching.

 

It depends what fits best your game. If your game requires fast and tight code and decoding ROM will affect the critical path, then bank-switching may be better since there wouldn't be much of that anyway: you switch once midway through player progress, and load the rest from the second bank.

 

I do understand that it may feel unclean to leave all that raw data taking up so much space, but personally I rather concentrate on the game-play logic and polishing details than on the boring technical stuff. Your mileage may vary.

 

If my game goes anywhere near that big, without data-encoding, it would be impossible to manage on this system.

With basic metatiles, that same data would only amount to 9360, and 10440 bytes, respectively.

 

8-bit bytes or 16-bit words? If the former, that comes to 9,900 DECLEs, if the latter then 19,800 DECLEs. Big savings indeed. Again, needed only if the conditions I mentioned above are true.

 

The short answer is--

This is an adventure game, where you explore a vast world, filled with dungeons. It's going to need unconventional storage methods.

Think Zelda 1, but a platformer.

I tend to get suspicious when new comers to the platform start talking about compression because they're used to having to cram a game into 4KB or 8KB. The Intellivision has vastly more space than that in modern cartridges (and certainly on ROM-only emulation), and the advertised "K" sizes represent thousands of 16-bit DECLEs, not bytes.

 

 

Sorry if I misunderstood your goal; I am not familiar with the game on which you are basing yours. If indeed the game is going to require such a large amount of data, then of course it's going to need compressed data structures.

 

Carry on!

Edited October 27, 2015 by DZ-Jay

[GroovyBee]

Are your HUD's "LIFE" and "EXP" values going to be numeric e.g. percentages or graphical bars? If its the latter you'll need to allocate some GRAM cards to store the "tip" of each graphical bar.

[Alp]

Fair enough.

 

 

I say, most of the time neither are problems.

 

 

It seems hard to convey that the space limitations of other platforms do not present themselves -- or at least not in the same significant way -- on the Intellivision. The Intellivision does have plenty of room, but it does have its limit.

 

 

That's a fair concern. Of course, if you are more comfortable implementing it that way, and it makes it easier, then that's the way to go. Besides, that might be easier than figuring out the intricacies of bank-switching.

 

(156 overworld + 174 dungeons) x 240 cells = 79,200 DECLEs in total (BACKTAB words are 16-bit wide). That is considering a full BACKTAB map for each screen. If you reserve the top row for a HUD (which you seem to have done), then that's 6.6K DECLEs less: 72,600 DECLEs

 

Without bank-switching, you can get away with about 42K DECLEs of ROM. Raw, uncompressed storage will require two banks of the available 16.

 

Yes, that is indeed quite a bit -- IF you intend to make the game that large, and IF every screen is indeed unique (I am not familiar with The Maze of Galious). Then of course, you'll need some sort of compression or bank-switching.

 

It depends what fits best your game. If your game requires fast and tight code and decoding ROM will affect the critical path, then bank-switching may be better since there wouldn't be much of that anyway: you switch once midway through player progress, and load the rest from the second bank.

 

I do understand that it may feel unclean to leave all that raw data taking up so much space, but personally I rather concentrate on the game-play logic and polishing details than on the boring technical stuff. Your mileage may vary.

 

 

8-bit bytes or 16-bit words? If the former, that comes to 9,900 DECLEs, if the latter then 19,800 DECLEs. Big savings indeed. Again, needed only if the conditions I mentioned above are true.

 

I tend to get suspicious when new comers to the platform start talking about compression because they're used to having to cram a game into 4KB or 8KB. The Intellivision has vastly more space than that in modern cartridges (and certainly on ROM-only emulation), and the advertised "K" sizes represent thousands of 16-bit DECLEs, not bytes.

 

 

Sorry if I misunderstood your goal; I am not familiar with the game on which you are basing yours. If indeed the game is going to require such a large amount of data, then of course it's going to need compressed data structures.

 

Carry on!

Your suspicion is fair enough--

...and I'm used to 32KB, not 8KB!

(That didn't stop me from programming 40(!) unique monsters within 512 bytes, with some clever programming.)

 

The screens on that console (the NES, to be specific) were 960 bytes each, uncompressed. Which is double what this console uses.

This might be an old-fashioned view-- but bank-switching should always be a last resort in 8-bit programming.

 

Every screen in this game is indeed meant to be unique, so keeping data size down is ideal.

This game wasn't a new idea when I decided to start programming it--

 

This concept was worked on last year, with some basic NES-restricted art started. So I already have a good idea of just how large this game will be.

 

Are your HUD's "LIFE" and "EXP" values going to be numeric e.g. percentages or graphical bars? If its the latter you'll need to allocate some GRAM cards to store the "tip" of each graphical bar.

Graphical bars, and I'm way ahead of you! 13-15 are reserved GRAM tiles for the status bars:

Which, with some clever color trickery (inverted tiles), can use multiple colors, to convey important information to the player.

Such as the percentage of current Life. Experience is solid green, regardless of the amount.

I mocked up the first boss monster for the game, and accounted for the Player sprite--

But *not* her sword! Damn it. This boss will need to "rotate" sprite cells, I suppose.

Once this monster is defeated, it splits apart into smaller Slimes, which split into "regular" enemies.

It has been suggested to me, that I should make the smaller Slimes merge back together if left unattended. I may add this as a secondary behaviour!

[+DZ-Jay]

This might be an old-fashioned view-- but bank-switching should always be a last resort in 8-bit programming.

 

 

Well, it's actually 16-bit 10-bit programming.

 

Just kidding. I hear ya'! I just think that, since most of us do this as a hobby and have very precious little time to apply to it, it may be better to put that time and effort into game logic, graphics, and all the important creative stuff, to get the game out; and leave the incidental stuff that is not germane to the game to the last resort. Like I said, your mileage may vary.

 

 

 

Once this monster is defeated, it splits apart into smaller Slimes, which split into "regular" enemies.

It has been suggested to me, that I should make the smaller Slimes merge back together if left unattended. I may add this as a secondary behaviour!

 

That's a cool idea! I like the game concept.

 

-dZ.

[+DZ-Jay]

Graphical bars, and I'm way ahead of you! 13-15 are reserved GRAM tiles for the status bars:

Why are you reserving 4 tiles for each monster? I don't think it's for 2-layered, 2x-vertical resolution sprites each because then you won't have any MOBs for the player avatar.

 

Also, know that you do not have to pre-load all animation/orientation cards into GRAM. You could dynamically cycle the cards of a MOB, though only on a VBLANK (frame) boundary. I typically stagger the animation rates (using fractional counters) to (almost) guarantee that all sprites never require a new tile on the same frame, and only update each MOB as needed. This gives me beautiful 60 Hz animation requiring only two cards in GRAM per sprite (for 2x-vertical resolution), leaving more space for background details.

 

Looking good!

 

-dZ.

[+nanochess]

Always you can use sprites magnified by 2x horizontal stretch and save sprites. I've used this in Princess Quest.

 

I like your finely defined player sprite, so you could use it for bosses.

 

[fsuinnc]

OK, so this game looks pretty freekin awesome! I have no help to offer as I can barely make a MOB move across the screen.

 

(I think it might be unfair for this game to be in the contest as the programmer seems to be both smart and talented giving him an unfair advantage. )

[Alp]

Why are you reserving 4 tiles for each monster? I don't think it's for 2-layered, 2x-vertical resolution sprites each because then you won't have any MOBs for the player avatar.

 

Also, know that you do not have to pre-load all animation/orientation cards into GRAM. You could dynamically cycle the cards of a MOB, though only on a VBLANK (frame) boundary. I typically stagger the animation rates (using fractional counters) to (almost) guarantee that all sprites never require a new tile on the same frame, and only update each MOB as needed. This gives me beautiful 60 Hz animation requiring only two cards in GRAM per sprite (for 2x-vertical resolution), leaving more space for background details.

 

Looking good!

 

-dZ.

The exact reason I reserved 4 slots, may have been a result of influence from my previous project, where the engine was hardcoded to a 3-enemy limit. (scanline limitation)

 

I do know that enemies don't need to be pre-loaded, the reserved RAM was so I could use the sprite size configuration to read sprite slots without needing to juggle any data around. At least, initially. If I have time, I will update the code, to dynamically select the sprite's address. (I hope this explanation makes sense?)

 

Always you can use sprites magnified by 2x horizontal stretch and save sprites. I've used this in Princess Quest.

 

I like your finely defined player sprite, so you could use it for bosses.

 

Oh crap, I keep forgetting you can do that!

It'll be helpful when I want to make larger bosses. I'll give a try, simplifying the largest slime.

 

Oh? You made Princess Quest? Neat! I saw this game on CollectorVision's page, last year.

OK, so this game looks pretty freekin awesome! I have no help to offer as I can barely make a MOB move across the screen.

 

(I think it might be unfair for this game to be in the contest as the programmer seems to be both smart and talented giving him an unfair advantage. )

I'm not "officially" entering the contest. My game is in this sub-forum, because the contest is what brought me here in the first place.

I wouldn't have entered, anyway. I hate being competitive.

[+DZ-Jay]

Oh crap, I keep forgetting you can do that!

It'll be helpful when I want to make larger bosses. I'll give a try, simplifying the largest slime.

 

 

Beware, it reduces the resolution and makes the sprite look chunkier. Personally, I'd prefer larger sprites to be a composite of multiple MOBs rather than magnifying -- unless you really need the MOBs for other things.

 

-dZ.

[fsuinnc]

I'm not "officially" entering the contest. My game is in this sub-forum, because the contest is what brought me here in the first place.

I wouldn't have entered, anyway. I hate being competitive.

 

I hope you know I just Kidding about you entering. I think the game looks great and I would have no complaints about you entering the contest, not that it is up to me. I was totally joking about my objections. Whether or not you choose to enter I look forward to the game and hope you enjoy creating it.

 

I get the competitive thing. I think the "contest" is really about getting people involved with the intellivision (starting with IntyBasic) and allowing more folks to be a part of the community. The fact that you (and several others) are now making games for the Inty means the contest is already a great success IMO.

[Alp]

Due to stress, this game is unlikely to be finished.

 

retroillucid has been given permission to use this game's art assets, as I will not be.

[artrag]

Sad to hear that.

Maybe you should have aimed to something less enormous

[artrag]

.

Edited November 15, 2015 by artrag

[GroovyBee]

Due to stress, this game is unlikely to be finished.

 

retroillucid has been given permission to use this game's art assets, as I will not be.

Shame! Don't shelve the game completely, just work on it as and when you have the time.

[+DZ-Jay]

Due to stress, this game is unlikely to be finished.

 

retroillucid has been given permission to use this game's art assets, as I will not be.

 

I completely understand and it is a shame. So you won't make it by the end of the competition, just work on it as you can. It does look like an interesting and fun project.

 

-dZ.

[Alp]

Sad to hear that.

Maybe you should have aimed to something less enormous

It's not this game that's the cause of stress. In fact--

The progress on the level 1 dungeon had 41 rooms finished.

 

I've made the decision to quit video game design entirely. I no longer find it fun.

 

Shame! Don't shelve the game completely, just work on it as and when you have the time.

I'm shelving all of my games, not just this one.

 

 

I completely understand and it is a shame. So you won't make it by the end of the competition, just work on it as you can. It does look like an interesting and fun project.

 

-dZ.

I won't be developing games anymore.

[Kiwi]

Take a break from it if you're stressed, and then come back to it. I usually take a break from game designing depending where the moon is in the sky. I figured for myself, no one is waiting so what's the rush.

[Rev]

It's not this game that's the cause of stress. In fact--

The progress on the level 1 dungeon had 41 rooms finished.

 

I've made the decision to quit video game design entirely. I no longer find it fun.

 

I'm shelving all of my games, not just this one.

 

I won't be developing games anymore.

Just read this... :-(

[retroillucid]

Shame! Don't shelve the game completely...

 

it's not!

[+cmart604]

 

it's not!

Awesome sauce ! J-F to the rescue! What can you tell us?

[retroillucid]

Awesome sauce ! J-F to the rescue! What can you tell us?

 

I'll make sure this game get released