Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - BlockQuest - towards Knights of the Round for the SMS

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
BlockQuest - towards Knights of the Round for the SMS
Post Posted: Fri Jul 11, 2014 10:30 am
I have uploaded my work in progress game to the homebrew section: http://www.smspower.org/Homebrew/Blockquest-SMS

I have a weakness for Capcom's arcade classic Knights of the Round.

Some day in the far future I hope to be able to create a cute/square 8-bit version/transformation for the SMS (see attached stuff). First I thought that I should embark right out on the project as my first real, from scratch, coding project. Then homsar47 uploaded his micro-game, and I got inspired to start out in a more fundamental way, with blocks, collision detection, library building, etc.

This way Blockquest was born, and is still living. I have tried to comment my code along the way (source included), and document as I go along.
Mockup.png (4.96 KB)
mockup of in-game - the dream
Mockup.png
Blockquest-SMS-Title.png (1.02 KB)
blockquest screenshot - the harsh reality :)
Blockquest-SMS-Title.png
sprite sheet.png (4.54 KB)
excerpt from sprite sheet
sprite sheet.png

  View user's profile Send private message Visit poster's website
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Fri Jul 11, 2014 9:52 pm
Looks pretty good!

Out of curiosity, how'd you get Block Quest onto the homebrew page?
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8113
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jul 11, 2014 9:59 pm
homsar47 wrote
Looks pretty good!

Out of curiosity, how'd you get Block Quest onto the homebrew page?

We are enabling edit access to whoever wants to contribute to the site!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8113
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jul 11, 2014 10:01 pm
Super cute mockups. With 8x8 characters you'll find that it'll be easyl to turn your program into the mockup!

Now on to play devil's advocate. What I have learned from Kun Kun & Kokokun is that such small and precise sprites works great with emulators and OK with RGB output. But anything else, component output or worse RF output which were most popular in the US, the visuals will take a big hit. I think this shouldn't stop you, but be aware that people without a RGB setup will lose a lot of the visual precision.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 255
  • Location: Angers, France
Reply with quote
Post Posted: Fri Jul 11, 2014 11:36 pm
Nice idea !
Like you I really love King of Dragons and Knights of the Round !

For your tilesets, i'think it's better to make a file which is 128 x 128px (16x16 tiles). And another one with 128 x 96px (16x12 tiles), so you reach the maximum tiles that can be loaded ; 448.
The first file go in the first bank, and the second...in the second bank.

Maybe your sprites can be 16x16 to make some super cute cubic characters ^^

If you make them in this way, I think it's better to make the sheet like the ones i've made for BOoM. I've put them "inline", so it's very easy to pick the next tiles to make a sprite.

For the background tiles, i much prefere to put them "myself" in a file than using the bmp2tile from Maxim, because I need to have some tiles always in the same order, and like this I can know exactly how many tiles i've made. But you'll need to use a tilemap editor like Tiled to make your levels.
Capture d’écran 2014-07-11 à 20.09.02.png (16.39 KB)
Boom - sprite sheet - 90 tiles
Capture d’écran 2014-07-11 à 20.09.02.png
Capture d’écran 2014-07-11 à 20.22.19.png (24.79 KB)
Lost Raider - City tileset - "Pink" is transparent
Capture d’écran 2014-07-11 à 20.22.19.png
Capture d’écran 2014-07-11 à 20.22.00.png (21.5 KB)
Lost Raider - City - tilemap (tiny extract)
Capture d’écran 2014-07-11 à 20.22.00.png

  View user's profile Send private message
  • Joined: 26 Jan 2014
  • Posts: 483
Reply with quote
Post Posted: Sat Jul 12, 2014 12:14 am
Wow, this level of Lost Raider is amazing!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12966
  • Location: London
Reply with quote
Post Posted: Sat Jul 12, 2014 10:18 am
BMP2Tile was never meant to be used for tilemaps except for static images. Once your game needs levels, you need to either write a tile engine that works with existing tools, or write tools yourself.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sun Jul 13, 2014 12:27 pm
Thanks for the feedback! I really appreciate it.

I created the page for Blockquest by typing the url, and then SMS-power gives you the opportunity to create the specified page with a homebrew template.

I'm inspired by your 8x8 games, Bock. I already use them for reference :) I can see the point about small sprites and RF output. I imagine a loss of quality. Then let's talk about VDP register 1, bit 0: Would it not give me über retro-looking zoomed 8x8 sprites? (As I read in Charles MacDonalds' fine document). And sprites zoomed like this don't count towards the 8 sprites pr. scanline limit, right? I can still have 8 zoomed sprites on a line?

For now I'll stick to the 8x8 sprites. That size suits me well at the moment, as I can handcode the graphics from the sprite sheets into the source file as needed. This gives me a feeling of total control... yes, I'm a fan of the multicolor letter "C" from p. 11 of the official software reference :)

For me it is also an attempt to work with, not against, the grain of the VDP, so to speak. One of the things I was not so proud of back in the days, was the flickering on my console. For the moment I consider it a design challenge to avoid ever having more than 8 sprites on a scanline. If Arthur is two sprites wide, then he is easily 3-4 sprites wide when poking with his sword. If Lancelot is on the same line, then there is little room for bad guys, let alone bosses. This might change though, I just like to try to avoid flicker at the moment.

It is really good advice to preformat the sprite/pattern-sheets so they will load smoothly into the VDP banks! Content for the "Getting Started"-section. I've thought about how to best organize pattern generator/tile bank stuff, but I'm a little 'damaged' by my Golden Axe and Altered Beast hacking projects, where patterns are redefined in the banks all the time. I'll definitely turn to preformatted sheets the moment I outgrow handcoding graphics :)

I handcode the level for now - it is not that much work yet :)
  View user's profile Send private message Visit poster's website
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Sun Jul 13, 2014 3:18 pm
hang-on wrote
I created the page for Blockquest by typing the url, and then SMS-power gives you the opportunity to create the specified page with a homebrew template.

The "New cartridge" button just redirects me to the home page...hmm.
  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Sun Jul 13, 2014 3:52 pm
@hang-on: Great mockup. I really love your style and the boxy little characters. "Knights of the Square" they are.

hang-on wrote
It is really good advice to preformat the sprite/pattern-sheets so they will load smoothly into the VDP banks! Content for the "Getting Started"-section.

Good idea. The method definitely keeps your animation frames nice and tidy, at least as long as there aren't a lot of them.

It's likely that you'll reach a point eventually, though, where you want to have just a few more frames of animation for your sprites and you'll simply run out of tiles. Then you have to decide if you want to reload certain sprite tiles (you can squeeze in a couple during Vblank) or if you organize your animation frames in such a way that some tiles from one frame can be reused in another that's not necessarily part of the same animation sequence.

I've attached the current sprite sheet from my own project. The player sprite's tiles (first 6) are dynamically re-loaded each Vblank, allowing for more frames and smoother animations. The green enemy has 35 frames of animation spread over 142 tiles (normally, that would be 210 for a six-tiles-character), the white enemy has 18 frames, consisting of 93 tiles (instead of 108). The last 5 slots in the sprite list are filled with new tiles during certain points of the game.

Of course, having 8x8 characters in the first place immensely helps. You can do a lot of animations and each frame only eats up one tile.


@ichigobankai: Wow. Lost Raider is still being developed? I don't know why, but somehow I had assumed that you had abandoned the project. Those city graphics look fantastic (as did the jungle/temple graphics from the preview version available in the homebrew section btw).
bl_sprites.png (3.89 KB)
bl_sprites.png

  View user's profile Send private message
  • Joined: 28 Sep 1999
  • Posts: 1146
Reply with quote
Post Posted: Sun Jul 13, 2014 7:46 pm
Quote
I can still have 8 zoomed sprites on a line?


Sure, just keep in mind that the zoomed sprites don't work correctly on a SMS or Genesis. They only look correct on the SMS2 and GameGear.

It's not an issue if you intend most people to play the game on an emulator, but if you want to put it on a real cart it will affect how many people can play it.

Quote
For the moment I consider it a design challenge to avoid ever having more than 8 sprites on a scanline.


To avoid this problem some SMS games drew objects into the background tiles, treating it as a bitmap of sorts. Gauntlet is a very good example where you have many moving objects on the same line. The disadvantage is that it takes a lot of time to do this, resulting in graphics updates being slower than 60 fps and jerky animation.

But since your game uses small objects you may be able to do this without sacrificing too much speed. Maybe you could drop the gameplay to 30fps, and reserve sprites for projectiles/weapons that move a lot and use the background for player/enemy objects.

Or just use this method for large objects like bosses and keep everything else as sprites. Regardless it's sort of complicated to program so perhaps it's better to stick with sprites for now. :)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Tue Jul 15, 2014 8:48 am
I'll be back! Right now camping w. no internet connection...
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sat Jul 19, 2014 11:09 am
Back from the wilderness :)

@Kagesan: Thanks for sharing your sheet and tips! I also work on a Alex Kidd modification with KiddEd, and from what I can see, that game also relies on organizing the animation frames in such a way, that some tiles from one frame, can be reused in another, that's not necessarily part of the same animation sequence. I will keep it in mind. Haha - and that is a great title. I will think of my game as "Knights of the Square" from now on :) .... "And Arthur created a square table for the square knights to sit around, so that they could square out important matters as equals..." ... "..or be on/around the same square in important matters..." well, pushing it here :)

@Charles: Thanks for your input (and for the great VDP document!). I wonder why they don't write about the zoomed sprites feature in the official Software Reference? Did they know it was broken on the SMS1, and then decided to ignore the feature, and not recommend it to developers? It is a shame that sprite zooming is not consistently possible across SMS1 and 2, GG and Megadrive.

What would the SDSC say/have said about zoomed sprites? Go or no go...

For now I'll just go with my small 8x8 sprites. My game is mostly for personal education anyway, and by now I have actually managed to get a two cell animated walking Arthur into Blockquest (tadaa!).
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Fri Jul 25, 2014 8:51 pm
Hi again.

I've expanded the map, and put Arthur 8x8 from the mockup in there. And he can walk, and collide with the walls on the map.I have uploaded everything to Blockquest's homebrew page.

Actually I think I'm going to shelve this project for a while. My approach so far has been 'problem-based-learning-as-you-go'. I have no master plan for the game/design, my wishes for new features spring from my small achievements along the way, and the problems I face as I want a sprite, a collision detection handler, etc.. This forward approach works somehow, but as my source expands, I find that it becomes increasingly hard to redesign/recode the stuff, that I've already put in, so that the new and the old parts will fit together.

I also find that I lack the theoretical/meta concepts for game design. Stuff like a hitboxes, velocity, game logic layer separated from graphics layer, animation, the 'state' of actors (including the player), etc.

I think I'll embark on some lesser projects that isolates game elements, and then try to come back to Blockquest when I have more experience, and can put the stuff together. I'm building the graphics, the library as I go. Who knows; when we are having the coding competition next spring, maybe Arthur and his square pals might resurface in Knights of the Square.
Blockquest-SMS-Title.png (1.34 KB)
Arthur himself - moving around!
Blockquest-SMS-Title.png

  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Sat Jul 26, 2014 7:14 am
hang-on wrote
I have no master plan for the game/design, my wishes for new features spring from my small achievements along the way, and the problems I face as I want a sprite, a collision detection handler, etc.. This forward approach works somehow, but as my source expands, I find that it becomes increasingly hard to redesign/recode the stuff, that I've already put in, so that the new and the old parts will fit together.

I don't think you necessarily need some kind of master plan to go ahead. If you read developers' journals from the 8- and 16-bit era, you'll see that most of them just made up the games as they went along.
Constantly recoding stuff is also quite a normal thing to do. My own project is a conversion of an existing game, so I know pretty much how my results are supposed to look, but still I keep going back and rewriting already working code to make it fit better with newly written stuff.

hang-on wrote
I also find that I lack the theoretical/meta concepts for game design. Stuff like a hitboxes, velocity, game logic layer separated from graphics layer, animation, the 'state' of actors (including the player), etc.

I think I've mentioned it before, but I cannot recommend enough Jonathan Cauldwell's excellent tutorial "How to write Spectrum games", which can be downloaded from his homepage here. He touches on most of those basic concepts and at least gives you an idea how to handle them. You can easily ignore the Spectrum-specific graphics and sound stuff.

hang-on wrote
Who knows; when we are having the coding competition next spring, maybe Arthur and his square pals might resurface in Knights of the Square.

I very much hope so. I really like where this is going.
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sun Jul 27, 2014 2:15 pm
Thank you very much for your support, Kagesan!

Somehow your input was exactly what I needed to find the courage and inspiration to constructively stay with Blockquest for yet another round of coding and feature adding :) Yesterday I added my first ever assembler switch case-like structure, with a jump table and everything, right in the middle of the existing code. I'm going for an attack state and animation, + a secondary sprite for Arthur's sword, as the next achievement, hehe :)

Where can I read developers journals? I really appreciate the bits in our own collection here at SMS-Power: http://www.smspower.org/Articles/STheSegaMagazine-Issue8-BackToTheFuture - where can I get more, and maybe even more detailed - stuff like that?

And thank you for the Spectrum game designer link. I thought I bookmarked it the first time you mentioned it, but now it is firmly integrated in my link collection.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Sun Jul 27, 2014 2:49 pm
hang-on wrote
Where can I read developers journals? I really appreciate the bits in our own collection here at SMS-Power: http://www.smspower.org/Articles/STheSegaMagazine-Issue8-BackToTheFuture - where can I get more, and maybe even more detailed - stuff like that?

Unfortunately, I don't know of any dealing with the SMS specifically, offhand.

I actually was thinking mainly of Andrew Braybrook's journals on the development of Paradroid and Morpheus which were published in Zzap64 in the mid-eighties. Although they deal with totally different hardware they give great insight into the decision processes and some of the technical problems encountered while making a game. Additionally, they are quite an amusing read.

Oh, and the same site also has journals on the development of Citadel and Lemmings.
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sun Jul 27, 2014 7:40 pm
Kagesan wrote
I actually was thinking mainly of Andrew Braybrook's journals on the development of Paradroid

This is great. I've read it, and I think it is very inspiring to know that even the pros make up the stuff as the go along, code, recode and everything.

And how can we complain in this day and age: Half way into the project his source needs 20 minutes for assembling, weird problems rising from bad disks, buggy debugging software, lightning strikes and power outs, etc. :)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
It scrolls!
Post Posted: Thu Aug 07, 2014 9:47 pm
Oh yes! I have finally managed to develop Blockquest into a sidescroller. Along the way I gave up hand coding graphics, and got rid of the very detailed block-by-block background collision detection scheme. Source included as always; it is not yet optimized in the ways we have discussed on the forum the past days, but it is firmly commented, and it gets the next scroll column filled before VBlank ends :) And by the way - Arthur can use his sword now...

Thanks for all the support so far. It has been very encouraging, and I'm glad I stuck with Blockquest, despite the sometimes painful and risky task of iterating through a growing source. Now I'm too deep in to go back. Music and sound effects, enemies, levels, scoring... If software is constructed/built, I'm having a fun-based treehouse-building approach to it: Mash something together, put some nails in, see if it stands, secure it a little more, move on to add something else, come back and tighten some screws, etc... Opportunistic prototyping.

Files uploaded to Blockquest's homebrew page: http://www.smspower.org/Homebrew/Blockquest-SMS

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8113
  • Location: Paris, France
Reply with quote
Post Posted: Thu Aug 07, 2014 10:00 pm
Super cute! I love the style.
I suggest doubling or tripling the walk speed :)
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Fri Aug 08, 2014 5:52 am
Great progress in such little time! I'm impressed.

I love the art style. Your code looks pretty neat, too. Certainly a lot less messy than mine. :) That bluelib of yours is a thing of beauty.

Keep up the excellent work. I can't wait to see more.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12966
  • Location: London
Reply with quote
Post Posted: Fri Aug 08, 2014 5:58 am
Hmm, is your keyboard missing some keys? All the variable names are missing some letters here and there... :)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Fri Aug 08, 2014 6:59 am
Just a quick reply before job starts today...

Thanks for the support - it is much appreciated!

@Bock: Yeah - I have thought about giving Arthur a running state, maybe when button 2 is pressed. Then he might move at triple speed :) Btw., we have touched upon this way of creating a level before: http://www.smspower.org/forums/viewtopic.php?t=14225&highlight=photoshop+editor - and you mentioned you made a separate map/layer for background collision detection. Could you please elaborate on that - I'm thinking about how to implement a simple background collision detection scheme. Max 10 objects pr. level (stones, barrels, etc.).

@Kagesan: Jonathan C.'s Spectrum document you pointed out has really been inspiring, also with regards to code formatting, etc.

@Maxim: Haha, I think it looks retro (OK, not so retro as in all uppercase). I even developed a coding convention around it to ensure maximum consistency:


Line length = max. 70 characters.

- Labels start in column 1
- Instruction mnemonics start in column 14
- operand field start in column 20
- inline comments start with a ";" in column 36, if operands extend
  into column 36, then insert two spaces before
  comment.

Example:
myString:    ld    a, (vertPos)    ; get the status byte                  *

Labels and variables:
- lowerCamelCase
- max. 8 characters
- max. two words

Assembler directives
- directive start in column 1
- lowercase
- comments preceding the directives as needed
- operands etc. after the directives, no column alignment

Exceptions
1) Constants, i.e.
   .define xxxxxxxx (max 8 chars, all caps) column 20 = value
    - this can have comments on from col 36+

2) Blocks of data, i.e.
   ; tiles for Arthur:
                .db   $00   (column 14 and 20)
                .db   $01
   Lowercase comment on preceeding line, ends with colon
   Note: Big data blocks should be in external files and included

3) Declaration of labels and variables, i.e.
   someVar      db                    ; my comment
  - comments can be from col 36+, ("db" at column 14)

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8113
  • Location: Paris, France
Reply with quote
Collision map
Post Posted: Fri Aug 08, 2014 7:57 am
See attached my collision map images for KunKun 2. You can also browse the sources for more details.

The idea is that I had a second "map" where each unique 8x8 block represent a collision data. It goes into Bmp2Title to which I gave a giant image composed of multiple screens. The first screens contains my "dictionary", one of each tile in a known order that matches the values in the code.

To be honest this is only a workaround for having a competent level editor but it worked quite neatly. In my drawing app I have one visual layer and one collision layer. One drawback is that dissociating visual and logic double the amount of data in ROM.

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12966
  • Location: London
Reply with quote
Post Posted: Fri Aug 08, 2014 9:20 am
One advantage is that any visual block can have any logical behaviour...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8113
  • Location: Paris, France
Reply with quote
Post Posted: Fri Aug 08, 2014 10:19 am
Maxim wrote
One advantage is that any visual block can have any logical behaviour...

Yes there is that flexibility of allowing that. Effectively I imagine most games have a higher level concept of "tile" that maps to visuals+logic and create some duplicate tiles for special case (=wall visual but no collision).
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Fri Aug 08, 2014 11:48 am
Bock wrote
The idea is that I had a second "map" where each unique 8x8 block represent a collision data. It goes into Bmp2Title to which I gave a giant image composed of multiple screens. The first screens contains my "dictionary", one of each tile in a known order that matches the values in the code.


Thank you very much. I'll look into it!
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 197
Reply with quote
Post Posted: Fri Aug 08, 2014 12:16 pm
There are three unused bits on the upper-byte of each screen name tile. Putting data into there would give you 8 possible values that you could directly tie to the tile on the screen without having to have a second map in memory.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 255
  • Location: Angers, France
Reply with quote
Post Posted: Fri Aug 08, 2014 12:24 pm
that's exactly what i've explained to hang-on by PM ^^
with vingazole we use this very little trick for lost raider
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Fri Aug 08, 2014 12:37 pm
ichigobankai wrote
that's exactly what i've explained to hang-on by PM ^^
with vingazole we use this very little trick for lost raider


Haha, yes - it has already been a very good day :) And I think Jonathan Cauldwell describes a (Spectrum) subroutine to get the name table element, including the unused bits, 'under' an x-y coordinate pair.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Go hunt for treasure
Post Posted: Fri Aug 15, 2014 10:09 pm
Real life and real work are doing their best to keep me off the SMS, but they will not succeed! 8-bit life will prevail!!

Since last time I have learned a bit about meta tiles, collision detection and music/sound effects. Some of this stuff is implemented in the fresh iteration of Blockquest (http://www.smspower.org/Homebrew/Blockquest-SMS)

I discarded the grid/cells approach to collision detection last time, and now I'm coming back with a math-based(?) bounding box approach for detecting if Arthur collides with gold packed chests. Approach inspired by Jonathan Cauldwell; I'll go add his z80 game maker tutorial to the "Getting Started" section right when I finish this post.

The chests are closed when they appear on the screen. You must hit them with your sword to open them. And then collect the gold inside. Who said King of Dragons?... Well, ahem.. not quite there yet :)

The chests are governed by a pseudo-random number generator. I adapted the one from the code snippets section here at SMS-Power. If it is good enough for Phantasy Star, it is also good enough for me. I honestly don't know what is happening in the code, but nice to be able to cut and paste something in.

And speaking of drawing on external sources, I have implemented two sound effects using Sverx's psglib library and vgm2psg tool. Using Deflemask I created a sound for the slashing sword (it sounds like someone getting slapped... room for improvement) and for when you pick up gold (it sounds like something from the pre-8-bit era, but I like it). The psglib package works out of the box as much as low level stuff can do - thanks Sverx!

Inspired by the journals Kagesan pointed me to, I'm just going ahead with the game, adding features as I need them. As I iterate through the source, hardcoded stuff and specialized routines sometimes are rewritten to be more generic and flexible, i.e. code that started as a specific test to detect collision between the Arthur and a chest, was eventually turned into a generic collision detection routine that could also handle collision detection between the sword and the chest.

Next up is handling scoring and the top status bar, and then some enemies.

Even though the background is still produced as one long tilemap by BMP2Tile, and thus not generated using metatiles during runtime, I think I'll keep that approach for now. I have thought it over, and in Knights of the Square the background is mostly... well, background (decoration). I think I can work around my need for routines for background coll. detection. At the moment, at least.

Now it has almost been two years since I re-discovered my SMS and discovered SMS-Power. I have been using various old, crappy computers along the way. Yesterday I decided to recognize that this hobby is not going to go away, and I finally awarded myself with a proper laptop for SMS-fun. For the first time ever, I can have a Meka or Emulicious workspace where I can see all the editors at the same time! Sweet.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Sat Aug 16, 2014 7:35 am
Beautiful.

One little suggestion, though: Check the order in which you draw the chests on screen and update their positions. It looks like the chests' scrolling lags one frame behind the background's. Reversing the order of updating the position and drawing it might fix that. (I haven't really looked at the code, just assuming.)
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sat Aug 16, 2014 3:58 pm
Thanks! :) and a great tip. Maybe I need to reorder drawing and updating. I'll look into it.

Edit: Good call Kagesan! I was writing chest updates to the ram buffer inside the frame interrupt AFTER this buffer had been copied to 'real' SAT for the given frame. I just had to switch the order of two routines to synchronize chest movement to background scroll.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Hack and slash!
Post Posted: Fri Aug 22, 2014 7:50 pm
A non-scrolling top menu bar is screaming for a score display... Block Quest can now display a 6 digit score on the topmost black ribbon. By the way, the word "SCORE" and the digit tiles are ripped from a sidescrolling ninja game, but which one is it?

Each chest is worth 400 points. But what about the enemies...

Or rather, one poor, isolated soldier is pinned to the ground, almost hoping you won't notice him. But he is one of Garibaldi's henchmen, so it is your knightly duty to bring him to justice. Approach him... slash him.. again! and again! And again a few times (the sword is dealing random damage 1 - 3, and the non-upgrade sword has a + 1 damage modifier) ... the soldier can sustain a total of 10 damage points before giving in.... 200 points to you!

OK - I'm wildly overselling the 'game' up there :) But the current version, uploaded to http://www.smspower.org/Homebrew/BlockQuest-SMS has indeed score display, scoring routines and an enemy sprite in place.

So far I have taken a kind of wild-west approach to the game's development. No road map. If I wanted something in, I just tried to implement it right in. This have worked great so far, but I think I need to spend some time now modulizing (break into modules?) and optimizing the code. I almost can't keep up with all the small hacks and patches anymore, and there is a growing issue of jump-spaghetti I need to attend to :)
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 482
Reply with quote
Post Posted: Fri Aug 22, 2014 8:56 pm
Wow this dying animation makes me feel so evil!
I've just murdered a defenseless person :(

Really really cool so far! Keep up the good work! Can't wait to discover other cool things in future releases :)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Fri Aug 22, 2014 9:25 pm
haha - thanks Calindro! Yeah, it is a brutal game :) Yet my boy was a little disappointed: "Where is the version where the soldier lies in a pool of blood?" The two of us had some collaboration on the sprite creation on the iPad, and he experimented a little too much with the red color, for my taste... :) Kids these days...
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Sat Aug 23, 2014 6:23 am
hang-on wrote
So far I have taken a kind of wild-west approach to the game's development. No road map. If I wanted something in, I just tried to implement it right in. This have worked great so far, but I think I need to spend some time now modulizing (break into modules?) and optimizing the code. I almost can't keep up with all the small hacks and patches anymore, and there is a growing issue of jump-spaghetti I need to attend to :)

What I do is this: When I want something new in the game, at first I just bolt it on. As soon as I notice, though, that I have to scroll too much through my code to update little things that belong basically to the same action, I break out chunks of code that belong together and put them in a seperate .inc file. Then I can start making a mess there without affecting my main code. :)

Joking aside, I know what you mean. Sometimes a little structure is needed if you want to retain your sanity further down the road. However, I think it's also important not to obsess about code efficiency too much. If it works, leave it and move on. If you run into trouble with either speed or data size, you can always go back and optimize things.
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sat Aug 23, 2014 7:52 am
Kagesan wrote
As soon as I notice, though, that I have to scroll too much through my code to update little things that belong basically to the same action, I break out chunks of code that belong together and put them in a seperate .inc file. Then I can start making a mess there without affecting my main code. :)

That is exactly my case at the moment :)

Still everything fits into the first 16 KB bank, and I'm rolling with uncompressed tiles and sound. So I don't worry on that front. Also there is still a lot of time left in the VBlank, so I'm not worrying too much about code optimization... yet.

From my days of playing Warcraft, I remember the concept "Fog of War". You can still see the basic features of the land you have discovered, but if you dont visit a place for some time, it becomes greyed/darkened, and important stuff like enemy troops etc. can be there, without showing up on your map. Could the asm equivalent maybe be "Fog of Development?" or "Fog of Coding"? :) . This is my main obstacle right now - my opponent is not the hardware, as much as it is myself. I.e. I had a pretty big facepalm moment yesterday when I realized I had put in a lot of effort and work-arounds to ensure that my sprite updating routine was never called outside my VBlank handler. Only to (re-)discover that it is of course working on my RAM buffer, and not the real SAT, as so it is completely safe to call it from anywhere in the code. Duh...
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Thu Sep 18, 2014 8:40 pm
A little postcard from the brewery.

Knights of the Square (working title: Blockquest) is still brewing, although at a far more modest pace. I have uploaded a new version to the homebrew section. A lot of changes have been put in, but most of those count as 'behind the scenes'-stuff.

http://www.smspower.org/Homebrew/BlockQuest-SMS

The game has changed a little towards a kind of Vigilante-style gameplay.

Hot new stuff:
1. Zoomed sprites! Yeah. Change a couple of bytes and KAPOW: Hello arcade size sprites. Hmmm, that might not be the most accurate description.

2. Meta tile-based sidescrolling background. I finally got around to implement some of the stuff about meta tiles we talked about in the summer. Paint Shop Pro 7 and BMP2Tile works great together!

3. Whole new structuring of the source. Stuff is broken down into semi-stand-alone modules (chest, player, score, etc.), so that I can work with i.e. the chest in an isolated space. Ahh, it feels nice, and contributes greatly to fighting the fog of coding :)

4. A totally messed up source. I'm half-way implementing my third coding convention as I go along (OK Maxim, you were right - it did not hold up with the 8 char retro style :)) I have two randomizer functions, obsolete functions, etc. But in spite of all this, I have never had an overview of the source this good. Sidenote: I now work with Knights of the Square in a Github respository, and it feels very comforting to have the versioning of whole directories available. I have rolled back changes more than once. And OK, I'll also admit that I'm sending pull requests to myself now and then... :)

5. Minor stuff like speeding up the movement, implementing collision detection, the thug is moving and attacking, etc.

Beware. One of these days I'll recieve my very first MIDI keyboard in the mail.

It started as a little red block. Now it's a 16x16 knight out to fight evil.

  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 462
Reply with quote
Post Posted: Fri Sep 19, 2014 2:05 pm
Very nice. It's just a pity that I can't play it on my real SMS, as it's a SMS, which doesn't support sprite scaling.

There's a rather amusing bug, though: If your way is blocked by a chest and you push in the direction of the chest, any enemy (dead or alive) on screen is still affected by push scrolling, even though neither the background nor the chest scroll anywhere.
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Fri Sep 19, 2014 3:32 pm
Haha - thanks. Yeah, it is a shame that sprite scaling is not supported across all models. The only real solution is to have multiple consoles in your collection :)

That bug. I know exactly where to fix it! Thanks for pointing it out.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2527
Reply with quote
Post Posted: Sat Sep 20, 2014 4:17 am
Kagesan wrote
Very nice. It's just a pity that I can't play it on my real SMS, as it's a SMS, which doesn't support sprite scaling.


I might be very wrong but I remember that feature wasn't one of those added with SMS2 (even if it is one absent on MD...)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sat Sep 20, 2014 5:52 am
sverx wrote
I might be very wrong but I remember that feature wasn't one of those added with SMS2 (even if it is one absent on MD...)


I play with my zoomed sprites on real hardware (SMS2). I think it is a question of a VDP bug in SMS1 that was fixed with SMS2. Charles McDonald describes it in his VDP documentation.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2527
Reply with quote
Post Posted: Sun Sep 21, 2014 2:35 am
Yes, it's buggy, not absent, as Charles' doc says:
Quote
There is a bug in how the original SMS VDP processes zoomed sprites compared to the SMS 2 and GG VDP; it will only allow the first four sprites of the eight shown on a scanline to be zoomed horizontally and vertically, and the remaining four will be zoomed vertically. The SMS 2 and GG allow all eight sprites to be zoomed in both directions.

So it means you can use that sprite zooming feature even on a 1st rev. SMS, if you pay attention to it (in my code I'm using this feature when I show 2 sprites only on screen so it's working correctly despite the bug...)
How many sprites do you display on the same scanlines?
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sun Sep 21, 2014 5:09 am
At the moment it is max. 4. Arthur + sword + thug + sword. But I plan to use all 8. When the swordman enemy appears, he will carry/drag a two-sprite wide sword. And I want up to two enemies on screen at the same time. I'm trying to avoid having to flicker the sprites.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2527
Reply with quote
Post Posted: Mon Sep 22, 2014 2:36 am
I see. So it's going to be an "SMS II only" release, as some CodeMasters games, correct?
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Tue Sep 23, 2014 6:07 pm
Yeah, I think you can say that :) I did not know that some real games actually were released for the SMS2 only.

... But then again, I don't even plan a release. I'm having fun with Blockquest, and I'm using it to get into the world of SMS-programming. So it is more of a process, and not a product. It is a project of personal education... undertaken in a public space :) And it is not finished yet, obviously.

So far, having chronicled the process from a stupid red block to 'real' sprites with collision detection and scrolling background in these forum posts, I hope to contribute, in a small way, to the 'Getting Started' movement in the SMS-community.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2527
Reply with quote
Post Posted: Wed Sep 24, 2014 12:52 am
hang-on wrote
I did not know that some real games actually were released for the SMS2 only.


I also didn't know that until I read on this forum about the 'extra-height' modes and the (few) games using them. I originally also planned to use the 256x224 resolution, which would have been just perfect for me... then when my Master Everdrive arrived I discovered that the leftmost column gets out of screen with my SMS II, and I was told about the 'safe area'.
So I gave up using both the leftmost and rightmost columns on the screen, and a 240x224 wasn't what I needed, so I switched to the normal height mode finally.

hang-on wrote
I don't even plan a release


It seems to me you're already doing that ;) (kidding, I see what you mean...)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 568
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Sat Oct 04, 2014 9:49 pm
Greetings!

New version is up, and here are the highlights:

    - the swordman is here, and he is coming at you!
    - title screen, with ultra compressed sound like sverx suggested in another thread. Hey sverx, I managed to boil it down to 216 bytes! Still not needing paging for my game...
    - level end screen
    - life meters for everyone. Only the bad guys get hurt, as I want to be able to roam around freely while developing...


Link to homebrew section: http://www.smspower.org/Homebrew/BlockQuest-SMS

I'm still just putting in stuff and features quick and dirty as I go along. But I'm sticking with the module-structure, and I try to create meaningful modules as I need them. There is a module for the player, for each of the enemies, the scoring system, etc. Each module (or section, but not in the WLA-DX sense) contains its own variables, definitions, routines, etc. And the main.asm keeps track of everything. I work with a homemade anti-spaghetti principle that dictates the following: One module can read another module's variables, but cannot write to these. Variables can only be updated by routines in the module they belong to. This gives me some flexibility, but helps keep the stuff in separate chunks, and I can safely edit i.e. the swordman without having to worry too much about breaking the scoring system in the process. Then I occasionally do some crazy stuff with flags signalling between the modules, but it works OK so far.

Earlier this week, I felt like the world champion of coding! Suddenly I realized that my VBlank handling stuff was bleeding almost 30 lines into the active display. At first I felt sorry for myself... But then I actually managed to work out which routines caused the trouble, and I also managed to optimize them (tadaa!), so that I'm now safely back in VBlank when my frame interrupt handler finishes. Then I thought: Maybe the guys working at the Linux kernel need a hand... :)

There are lots of inefficient stuff going on inside the code. On my list of TODO's for code optimization is finding a better way to handle the states of my different objects, i.e. the swordman can be standing, walking, attacking, dying, off, etc. I imagine a good way could be to implement a kind of switch case structure to respond to the different states. And I'm looking into vector/jump tables for that job.

I'm not going for an epic adventure with Knights of the Square. At the moment I would like to implement a boss in level 1, and then add a second level that builds entirely on the level 1 engine, but with adjusted graphics and key parameters.

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12966
  • Location: London
Reply with quote
Post Posted: Sun Oct 05, 2014 8:03 am
There's no real need to finish your VBlank routine before line 0, just so long as the fast VRAM accesses finish before that. You can run your whole game in there, with a minimal loop outside, or vice versa.
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!