Forums

Hello.

In my free time I decided to make a small demo with all the basic stuff of a game: crappy wall collision, crappy movement, and crappy joypad detection. (What can I say, it's my first SMS game ever).

The source code was organized so that code snippets can be cut out easily, and not everything is highly cryptic. Hopefully I succeeded. XD

Anyway, enjoy!

BitTest.zip (15.17 KB)

It's nice that it has a structure, with intro, levels, etc.!

To turn it into more of a game, some chunks could disappear as you walk on them? collect bits? avoid bits? then levels become custom bitmaps (rather than rectangle?) just throwing ideas in the air.

Bock wrote

It's nice that it has a structure, with intro, levels, etc.!

To turn it into more of a game, some chunks could disappear as you walk on them? collect bits? avoid bits? then levels become custom bitmaps (rather than rectangle?) just throwing ideas in the air.

Thanks, I'll take said ideas into consideration.

Thanks for sharing this! Nice, simple and good to learn from :)

hang-on wrote

Thanks for sharing this! Nice, simple and good to learn from :)

Indeed, thanks. For what is basically a 'hello world' it's an outstanding effort, and I really like that you included the source code.

Speaking of that, however, it would have been nice if you had structured the code blocks with line feeds for easier reading, and commented them. I know it's a fairly short piece of code and, at this moment, you probably know what every routine is doing and how it's doing it, so commenting may seem like some unnecessary hassle. But trust me, if you take a look at the code you know in and out now in, say, half a year from now, you'll probably have a hard time understanding what you were doing if you don't include comments.

Suggestions:

- Whitespace, as above
- Lowercase directives
- Use your defines for port numbers
- Avoid macros, my experience was to confuse them with actual functions
- Don't name your macro args as ONE, TWO etc and then not use them - either give them useful names or not
- Document (in comments) what the macros and functions are for, the names aren't enough and don't help explain what the parameters are
- SetTiles is actually LoadTilesToVRAMAtIndex0
- It would be better to provide all the raw data as something convertible to tiles, tilemaps, palettes and demonstrate the conversion (BMP2Tile or otherwise)
- Your indentation style is confusing, it seems to be 4 spaces indentation if within a loop, but only the outer loop is considered.
- InitSMS sets most VDP registers twice?
- Either use a ramsection or export your memory enum, to make debugging easier
- Your macros are hiding some weird code. No game would read the controller port for every button check, for example.
- I'd separate things for the "movement engine":
-- Code to read the controls into RAM
-- Code to take those controls and edit X, Y variables in RAM accordingly
-- Code to clamp those X and Y to the boundaries
-- Code to check if you have hit the exit
-- Code to set the sprite X, Y
- I can't see where you are waiting to do all this once per frame (you'll get debouncing issues on real hardware if you don't), nor can I see where you're making sure to update VRAM in the VBlank (you'll get corruption on real hardware). The use of a busy-loop delay is probably helping with debouncing but it's setting a bad example.
- ClearText shouldn't need a table of zeroes.
- The cup doesn't look much like a cup.

I'm almost inclined to produce a copycat version in my own style as that'd be more helpful than the above...

Kagesan and Maxim, thanks for the (not-so-surprisingly high XD) amount of suggestions. I'll see what I can do.

The end product is more important than the source code, so you don't have to apply coding tips verbatim. It is more valuable to be confident within your own code. Only adopt a tip if you thnik it'll improve your productivity and your output but not for the sake of beautifying source code. Aka ignore the source code nazis above and prioritize making a game! :-)

Bock wrote

The end product is more important than the source code, so you don't have to apply coding tips verbatim. It is more valuable to be confident within your own code. Only adopt a tip if you thnik it'll improve your productivity and your output but not for the sake of beautifying source code. Aka ignore the source code nazis above and prioritize making a game! :-)

Hey, I just want to have good habits for other stuff I make, starting with this. XD The enthusiasm is appreciated, though.

Bock wrote

Aka ignore the source code nazis above and prioritize making a game! :-)

LOL :D

No, seriously, what I hate the most is when I read someone source code and I swear at it... while the original author is me ;)

sverx wrote

Bock wrote

Aka ignore the source code nazis above and prioritize making a game! :-)

LOL :D

No, seriously, what I hate the most is when I read someone source code and I swear at it... while the original author is me ;)

Why, did I steal code from you and just forgot?

I think it would be great to make a foundation for development a bit more advanced than my Hello World tutorial, but certainly there's no chance to please everyone :)

homsar47 wrote

Why, did I steal code from you and just forgot?

No, I just meant that it's even worse when the bad source code I'm reading is my own ;)

I try to remember to make my code suitable for an idiot who had no idea what it is for or how it works, because experience has shown that idiot is often me six months later.

That's what I tried to say :D

Bock wrote

Aka ignore the source code nazis above and prioritize making a game! :-)

LOL

"No code for you!"

Maxim wrote

Suggestions:
- Either use a ramsection or export your memory enum, to make debugging easier
- Your macros are hiding some weird code. No game would read the controller port for every button check, for example.
-- Code to read the controls into RAM
-- Code to take those controls and edit X, Y variables in RAM accordingly
-- Code to clamp those X and Y to the boundaries
-- Code to check if you have hit the exit
-- Code to set the sprite X, Y
- I can't see where you are waiting to do all this once per frame (you'll get debouncing issues on real hardware if you don't), nor can I see where you're making sure to update VRAM in the VBlank (you'll get corruption on real hardware). The use of a busy-loop delay is probably helping with debouncing but it's setting a bad example.

Pretty much all the suggestions in the quote I don't know how to fix (the ones I could fix, I removed). Like, how do I avoid reading the controller for every button check?

Bump. (I hate those as much as you do).

Really, I'm curious as to how to fix some of the problems Maxim pointed out.

I had a go at making an example but it got messy as I started trying to do everything else too. I'll try to write a longer description...

homsar47 - your little program was somehow just what I needed to get started writing my own program from scratch. My 'game' is also about blocks at the moment. Thanks for the inspiration! :) It's not really a game, but more like an attempt at grappling with collision detection, library making, coding practices, etc.At the moment you can control a red block on a small level. Oh wow... :)

Sverx's open source PSG library, all the talk about devkits, and a new "Getting Started" section here at SMS-Power, has got me trying my hand at developing my own library for VDP, controllers, etc., to go with the game.

I have attached assembled version, as well as source for Block Quest and the Bluelib-library. Work in progress. Summertime is SMS-time!

BlockQuest.zip (10.89 KB)

Demo w. source code

Cool, hang-on! Glad to see I gave some inspiration.

Thanks homsar47!

I will create a separate thread for BlockQuest, in order to avoid hijacking your thread even more. Even though I think of BlockQuest as a kind of 'response' to your game (I try to address some of the issues raised by Maxim), I don't want to divert attention from your work or questions!

Author	Message
homsar47 Joined: 16 Dec 2013 Posts: 69	BitTest, a Small Demo I Made Posted: Mon Jun 30, 2014 9:24 am
homsar47 Joined: 16 Dec 2013 Posts: 69	Hello. In my free time I decided to make a small demo with all the basic stuff of a game: crappy wall collision, crappy movement, and crappy joypad detection. (What can I say, it's my first SMS game ever). The source code was organized so that code snippets can be cut out easily, and not everything is highly cryptic. Hopefully I succeeded. XD Anyway, enjoy! BitTest.zip (15.17 KB)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8663 Location: Paris, France	Posted: Mon Jun 30, 2014 9:58 am
	It's nice that it has a structure, with intro, levels, etc.! To turn it into more of a game, some chunks could disappear as you walk on them? collect bits? avoid bits? then levels become custom bitmaps (rather than rectangle?) just throwing ideas in the air.

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Mon Jun 30, 2014 11:18 pm
homsar47 Joined: 16 Dec 2013 Posts: 69	Bock wrote It's nice that it has a structure, with intro, levels, etc.! To turn it into more of a game, some chunks could disappear as you walk on them? collect bits? avoid bits? then levels become custom bitmaps (rather than rectangle?) just throwing ideas in the air. Thanks, I'll take said ideas into consideration.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Tue Jul 01, 2014 7:37 pm
	Thanks for sharing this! Nice, simple and good to learn from :)

Kagesan Joined: 01 Feb 2014 Posts: 885	Posted: Wed Jul 02, 2014 4:34 pm
Kagesan Joined: 01 Feb 2014 Posts: 885	hang-on wrote Thanks for sharing this! Nice, simple and good to learn from :) Indeed, thanks. For what is basically a 'hello world' it's an outstanding effort, and I really like that you included the source code. Speaking of that, however, it would have been nice if you had structured the code blocks with line feeds for easier reading, and commented them. I know it's a fairly short piece of code and, at this moment, you probably know what every routine is doing and how it's doing it, so commenting may seem like some unnecessary hassle. But trust me, if you take a look at the code you know in and out now in, say, half a year from now, you'll probably have a hard time understanding what you were doing if you don't include comments.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14758 Location: London	Posted: Wed Jul 02, 2014 6:09 pm
	Suggestions: - Whitespace, as above - Lowercase directives - Use your defines for port numbers - Avoid macros, my experience was to confuse them with actual functions - Don't name your macro args as ONE, TWO etc and then not use them - either give them useful names or not - Document (in comments) what the macros and functions are for, the names aren't enough and don't help explain what the parameters are - SetTiles is actually LoadTilesToVRAMAtIndex0 - It would be better to provide all the raw data as something convertible to tiles, tilemaps, palettes and demonstrate the conversion (BMP2Tile or otherwise) - Your indentation style is confusing, it seems to be 4 spaces indentation if within a loop, but only the outer loop is considered. - InitSMS sets most VDP registers twice? - Either use a ramsection or export your memory enum, to make debugging easier - Your macros are hiding some weird code. No game would read the controller port for every button check, for example. - I'd separate things for the "movement engine": -- Code to read the controls into RAM -- Code to take those controls and edit X, Y variables in RAM accordingly -- Code to clamp those X and Y to the boundaries -- Code to check if you have hit the exit -- Code to set the sprite X, Y - I can't see where you are waiting to do all this once per frame (you'll get debouncing issues on real hardware if you don't), nor can I see where you're making sure to update VRAM in the VBlank (you'll get corruption on real hardware). The use of a busy-loop delay is probably helping with debouncing but it's setting a bad example. - ClearText shouldn't need a table of zeroes. - The cup doesn't look much like a cup. I'm almost inclined to produce a copycat version in my own style as that'd be more helpful than the above...

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Wed Jul 02, 2014 6:51 pm
homsar47 Joined: 16 Dec 2013 Posts: 69	Kagesan and Maxim, thanks for the (not-so-surprisingly high XD) amount of suggestions. I'll see what I can do.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8663 Location: Paris, France	Posted: Wed Jul 02, 2014 7:01 pm
	The end product is more important than the source code, so you don't have to apply coding tips verbatim. It is more valuable to be confident within your own code. Only adopt a tip if you thnik it'll improve your productivity and your output but not for the sake of beautifying source code. Aka ignore the source code nazis above and prioritize making a game! :-)

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Wed Jul 02, 2014 7:16 pm
homsar47 Joined: 16 Dec 2013 Posts: 69	Bock wrote The end product is more important than the source code, so you don't have to apply coding tips verbatim. It is more valuable to be confident within your own code. Only adopt a tip if you thnik it'll improve your productivity and your output but not for the sake of beautifying source code. Aka ignore the source code nazis above and prioritize making a game! :-) Hey, I just want to have good habits for other stuff I make, starting with this. XD The enthusiasm is appreciated, though.

sverx Joined: 05 Sep 2013 Posts: 3859 Location: Stockholm, Sweden	Posted: Wed Jul 02, 2014 8:02 pm
	Bock wrote Aka ignore the source code nazis above and prioritize making a game! :-) LOL :D No, seriously, what I hate the most is when I read someone source code and I swear at it... while the original author is me ;)

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Wed Jul 02, 2014 8:20 pm
homsar47 Joined: 16 Dec 2013 Posts: 69	sverx wrote Bock wrote Aka ignore the source code nazis above and prioritize making a game! :-) LOL :D No, seriously, what I hate the most is when I read someone source code and I swear at it... while the original author is me ;) Why, did I steal code from you and just forgot?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14758 Location: London	Posted: Wed Jul 02, 2014 9:06 pm
	I think it would be great to make a foundation for development a bit more advanced than my Hello World tutorial, but certainly there's no chance to please everyone :)

sverx Joined: 05 Sep 2013 Posts: 3859 Location: Stockholm, Sweden	Posted: Thu Jul 03, 2014 7:28 am
	homsar47 wrote Why, did I steal code from you and just forgot? No, I just meant that it's even worse when the bad source code I'm reading is my own ;)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14758 Location: London	Posted: Thu Jul 03, 2014 7:41 am
	I try to remember to make my code suitable for an idiot who had no idea what it is for or how it works, because experience has shown that idiot is often me six months later.

sverx Joined: 05 Sep 2013 Posts: 3859 Location: Stockholm, Sweden	Posted: Thu Jul 03, 2014 8:21 am
	That's what I tried to say :D

Kagesan Joined: 01 Feb 2014 Posts: 885	Posted: Thu Jul 03, 2014 4:38 pm
Kagesan Joined: 01 Feb 2014 Posts: 885	Bock wrote Aka ignore the source code nazis above and prioritize making a game! :-) LOL "No code for you!"

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Fri Jul 04, 2014 1:20 am
homsar47 Joined: 16 Dec 2013 Posts: 69	Maxim wrote Suggestions: - Either use a ramsection or export your memory enum, to make debugging easier - Your macros are hiding some weird code. No game would read the controller port for every button check, for example. -- Code to read the controls into RAM -- Code to take those controls and edit X, Y variables in RAM accordingly -- Code to clamp those X and Y to the boundaries -- Code to check if you have hit the exit -- Code to set the sprite X, Y - I can't see where you are waiting to do all this once per frame (you'll get debouncing issues on real hardware if you don't), nor can I see where you're making sure to update VRAM in the VBlank (you'll get corruption on real hardware). The use of a busy-loop delay is probably helping with debouncing but it's setting a bad example. Pretty much all the suggestions in the quote I don't know how to fix (the ones I could fix, I removed). Like, how do I avoid reading the controller for every button check?

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Thu Jul 10, 2014 2:49 am
homsar47 Joined: 16 Dec 2013 Posts: 69	Bump. (I hate those as much as you do). Really, I'm curious as to how to fix some of the problems Maxim pointed out.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14758 Location: London	Posted: Thu Jul 10, 2014 7:06 am
	I had a go at making an example but it got messy as I started trying to do everything else too. I'll try to write a longer description...

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Fri Jul 11, 2014 7:34 am
	homsar47 - your little program was somehow just what I needed to get started writing my own program from scratch. My 'game' is also about blocks at the moment. Thanks for the inspiration! :) It's not really a game, but more like an attempt at grappling with collision detection, library making, coding practices, etc.At the moment you can control a red block on a small level. Oh wow... :) Sverx's open source PSG library, all the talk about devkits, and a new "Getting Started" section here at SMS-Power, has got me trying my hand at developing my own library for VDP, controllers, etc., to go with the game. I have attached assembled version, as well as source for Block Quest and the Bluelib-library. Work in progress. Summertime is SMS-time! BlockQuest.zip (10.89 KB) Demo w. source code

homsar47 Joined: 16 Dec 2013 Posts: 69	Posted: Fri Jul 11, 2014 7:55 am
homsar47 Joined: 16 Dec 2013 Posts: 69	Cool, hang-on! Glad to see I gave some inspiration.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Fri Jul 11, 2014 9:23 am
	Thanks homsar47! I will create a separate thread for BlockQuest, in order to avoid hijacking your thread even more. Even though I think of BlockQuest as a kind of 'response' to your game (I try to address some of the issues raised by Maxim), I don't want to divert attention from your work or questions!

Forums

View topic - BitTest, a Small Demo I Made