Its just that I don't see the point in not offering it.
Its not as if it is [whisper] top secret [/whisper] or anything.
I just thought others may enjoy reading it and that it may encourage other game developers to do the same so more people learn how to write code for machines that are 20+ years old.
The more code thats out there the more likely alot of other people will give assembly programming a go.
Seriously though who out there wouldn't love to see some of Jonathan's code for his games?
I know I would.
I would never ask him or anyone else to release their code if I wasn't willing to at least do the same first.
Just happy that someone likes it and that people are interested enough to look through the code.
Oh and the web site has being updated to, so you can check out the code too now.
And if anyone manages to fix any bugs please forward the fix onto me, so I can include it in the final version.
Why not compile it in TG and find out if you are right
I tried to compile it and it complained about not having a tool to assemble. I've configured it and compiled it now, but unless I get a snapshot where the old code failed and the new doesn't, I can't prove for sure if the fix is right...
This could be true.
r and b, are Right and Bottom values.
They are used to trigger a carry flag when added to the current pattern matching position.
So if the current position causes a carry then the current position is not valid for that pattern. ie. it goes off the screen.
The PossiblesTable contains all the possible patterns that would allow the game to continue.
If a possible pattern is found then the game can continue, it will also be used to show the player hints in the future when they get stuck.
I don't have a current gem layout table, I use the attributes display instead which is why all the patterns are offset by 24 each time.
The gem tiles are 24x24.
Yes I could optimize both the table and code to use 3 chars instead of 24 pixels, but speed is not an issue here and I prefer using the pixel values.
I must confess to not having complete debugged the tables so far.
You get to a point where your seeing things and believe whole heartedly that want your seeing is what you intended.
But computers being computers, only do as they are told and sometimes you give them the wrong instructions. ;)
Keep up the good work MetalBrain,... I expect you should have the game finished by the weekend ;)
If you keep fixing bugs at this rate I'll have to put your name on the credits. :)
It is a legal combination, and I do know of the problem and will try to fix before my next release.
Graphics corruption happens on all tilesets, will fix that soon as well.
AS_Loop: call AS_CheckAll ; check all the board for any matching gem patterns
AS_Cont: call c, ReplaceGems ; remove and score the matching gems
jr c, AS_Loop ; keep going until no matches are left
call AS_BonusAdd ; add any bonus values
call CheckLevelGO ; check for next level and game over conditions
[color=red]ld bc, (PointerPos) ; get the pointer position[/color]
[color=red]call DrawPointer ; draw the poinet in the new position[/color]
call DrawGemCursor ; draw the gem board cursor
jr AS_End ; swap is complete
This fixes the graphic corruption when doing a successful swap, by updating the pointer background info. No more mixed pieces.
Hmmm... there's still a bit of screen corruption out there, must keep investigating...
ActionSwap: call EraseGameCursor ; remove the game cursor
call AS_BonusReset ; reset the bonus counter
ld bc, (CursorPos) ; retrieve the current cursor position
ld (AS_Tile1Pos), bc ; and store it as the first tile position
ld bc, (CursorPosOld) ; retrieve the the previous cursor position
ld (AS_Tile2Pos), bc ; and use it as the second tile position
[color=red]ld bc, (PointerPos) ; get the pointer position[/color]
[color=red]call ErasePointer ; erase the pointer before swap animation[/color]
call AnimateGemSwap ; animate the gem swapping
The new corruption was produced because the extra Drawpointer of the bugfix above was drawn over the new cells just swapped, but could also be partly draw over the old cell below it, so it took the cursor itself as a part of that cell below.
I'm done for today... Good luck with the complex movements fix.
Cheers and thanks for the help.
I would of fixed them you know, no really i would of... eventually ;)
You'll have to tell me your thoughts on the code.
It can't be too badly coded if your fixing bugs within the first hours of downloading it. :)
Remember this game is a team effort so far, especially from RetroCoder/Mr millside, Lee_Dc and now MetalBrain too. (oh and me too, I think some of my code is in there somewhere ;))
You'll have to tell me your thoughts on the code.
It can't be too badly coded if your fixing bugs within the first hours of downloading it.
I haven't been looking through all the code, it seems not to be too optimized (or maybe it's not optimized at all), and some design decisions seem a bit weird to me, but above all it's very well structurated and commented, so I had no problems at all finding the relevant routines to bugfix, and following them. Nice work on that!.
No need to optimize anything because,
a) its a puzzle game and hardly exercises the cpu too much (except the scrolling)
b) there is plenty of memory available for this game to use
c) readability is more important that speed at the moment
As for design decisions, well there aren't any. Its a make it up as I go along approach, so yeah some them are a bit weird.
I'm using this as an exercise in stress testing TommyGun and finding the things in TG that piss me off and need fixing.
Like I wish I had an inbuild debugger in TG.
But that would require me to write(borrow) an emulator core and produce a debugger interface for it. Too much other stuff to do.
I have considered Fuse and would definitely use it when I'm ready to GPL TommyGuns source code.
But want I <b>really</b> would like is a machine independent emulator core and debugger interface. You then write a machine specific component/plugin for the core to support the desired machine/hardware. eg. Speccy, CPC, C64, ZX81 etc
I suppose its similar to how MAME works in that mame supports many arcade machines through a single interface. (I think)
So anyway with this system TommyGun could then support a single debugger interface and multi machines within its IDE.
It would be as close to a Cross Platform (ie Machines) VisualStudio style development environment you would ever get.
But its a pipe dream, probably not going to happen.
Its just an idea of where TG could go in the future if the support was there for such a thing.
Thats not to say I won't at least give Fuse a try in the future to test the concept.
Remember this game is a team effort so far, especially from RetroCoder/Mr millside, Lee_Dc and now MetalBrain too. (oh and me too, I think some of my code is in there somewhere ;))
I'm back from my two week holiday so I'll grab the latest build on Monday and will start looking for bugs my self. Looks like the menu stuff is working well :)
What about diagonals could it be made to allow you to make diagonal lines or would that make the game to easy.
Its not in the bejewelled game rules.
Its too easy now, let alone with diagonals as well.
Your free to add them if you like at a later date, but not at the moment until the game is complete.
There should be a new version possibly on the weekend, with the bugs fixed that people have suggested and more playability. http://www.users.on.net/~tonyt73/TommyGun/
goto Projects section
I have considered Fuse and would definitely use it when I'm ready to GPL TommyGuns source code.
But want I <b>really</b> would like is a machine independent emulator core and debugger interface. You then write a machine specific component/plugin for the core to support the desired machine/hardware. eg. Speccy, CPC, C64, ZX81 etc
I suppose its similar to how MAME works in that mame supports many arcade machines through a single interface. (I think)
So anyway with this system TommyGun could then support a single debugger interface and multi machines within its IDE.
It would be as close to a Cross Platform (ie Machines) VisualStudio style development environment you would ever get.
But its a pipe dream, probably not going to happen.
Its just an idea of where TG could go in the future if the support was there for such a thing.
Thats not to say I won't at least give Fuse a try in the future to test the concept.
Have you looked at MESS? It's based on MAME but emulates old computers. http://www.mess.org/
Rainbow IDE for the Tandy CoCo (and other systems) lets you assemble your code, transfer the executable to a disk image and then launch the MESS emulator with your disk already loaded and ready to test. http://www.rainbowide.com/
There should be a new version possibly on the weekend, with the bugs fixed that people have suggested and more playability. http://www.users.on.net/~tonyt73/TommyGun/
goto Projects section
Any updates?
I tried downloading the zip file and it appears you have taken it offline.
Have you looked at MESS? It's based on MAME but emulates old computers. http://www.mess.org/
Unfortunately MESS's stable of emulators are not the best available. Particularly relevant to this forum, the spectrum emulator is lacking in features and accuracy.
Rainbow IDE for the Tandy CoCo (and other systems) lets you assemble your code, transfer the executable to a disk image and then launch the MESS emulator with your disk already loaded and ready to test. http://www.rainbowide.com/
What makes TG different is that it contains resource editors tailored for each architecture. Eg, there's an image editor, sprite editor, font editor, text editor. Code can include data from those editors and if any resource is changed, all updates are taken care of.
Unfortunately TG's not being further developed. I don't want to speak for Kiwi but I think he needs a break and will get the itch to come back and finish it off. Adding an api for 3rd party editors and data exporters would be some right-nice polish :-)
Have you looked at MESS? It's based on MAME but emulates old computers. http://www.mess.org/
Rainbow IDE for the Tandy CoCo (and other systems) lets you assemble your code, transfer the executable to a disk image and then launch the MESS emulator with your disk already loaded and ready to test. http://www.rainbowide.com/
Yes I have seen MESS. I found it on source forge when looking for debuggers.
As AA says in his post above, my main concern was the speccy support is pretty lacking.
The Rainbow IDE does look impressive but $45US impressive, I'm not sure. ;)
Again as AA says, there are no resource editors???
I feel the main strength of TommyGun is the extensibility of it all.
You can use any assembler/C package and any emulator.
It will update resources automagically for you.
But sadly it doesn't write all the code for you.
The only thing I think missing from TG would be if all emulators supported a common debugger interface, and thus TG could also contain a debugger.
That way the debugger stays independent of the platform and TG would work regardless of the emulator.
Alas this is dream that just may not be possible unless I got support from the emulator authors.
AA again got something else correct as well.
I am a little tired and need a break from TommyGun and will return it to one day.
But at the moment I just stick to fixing bugs and odd feature request here and there.
I will add the API for 3rd party developers as well so people can use Visual C++ to develop plugins.
And I will also be changing the code parsers to use a custom designed scripting language that will also have built in support for creating the GUI components.
I also checked the TommyGun project links and they work fine, no files are missing.
Thanks JamesD for your input its very much appreciated.
Cheers to AA as well.
Yes I have seen MESS. I found it on source forge when looking for debuggers.
As AA says in his post above, my main concern was the speccy support is pretty lacking.
Sadly the same is true for many machines emulated by MESS.
Emulator developers all seem more interested in their own emulators than a community one like MESS.
The Rainbow IDE does look impressive but $45US impressive, I'm not sure. ;)
Yeah, I thought that was a bit much but it does let you try it free if you don't mind the little nag window that shows up over the button to build your project.
Again as AA says, there are no resource editors???
It does kinda limit it. There are some other environments that launch a single emulator but I don't know if any of them have a resource editor.
I feel the main strength of TommyGun is the extensibility of it all.
You can use any assembler/C package and any emulator.
It will update resources automagically for you.
But sadly it doesn't write all the code for you.
The only thing I think missing from TG would be if all emulators supported a common debugger interface, and thus TG could also contain a debugger. That way the debugger stays independent of the platform and TG would work regardless of the emulator.
Alas this is dream that just may not be possible unless I got support from the emulator authors.
Send a few emails and see if you can start discussion on an open standard.
I'm sure a few comments from people to the authors encouraging this wouldn't hurt.
Btw, I'm a software engineer and I can totally understand you needing a break.
I also checked the TommyGun project links and they work fine, no files are missing.
I'll go back and check. It might just be the link I tried and I'm not even sure where I got it.
Thanks JamesD for your input its very much appreciated.
Cheers to AA as well.
Comments
Its not as if it is [whisper] top secret [/whisper] or anything.
I just thought others may enjoy reading it and that it may encourage other game developers to do the same so more people learn how to write code for machines that are 20+ years old.
The more code thats out there the more likely alot of other people will give assembly programming a go.
Seriously though who out there wouldn't love to see some of Jonathan's code for his games?
I know I would.
I would never ask him or anyone else to release their code if I wasn't willing to at least do the same first.
I shall put it up on my site tonight then!
www.users.on.net/~tonyt73/TommyGun
goto to projects section.
Great to see the game though Kiwi, i didnt think it would be Vapourware but you never know with some of these releases !
The game looks great and plays very well. Cant WAIT for you to do the next game !!!! Much appreciated
Just happy that someone likes it and that people are interested enough to look through the code.
Oh and the web site has being updated to, so you can check out the code too now.
And if anyone manages to fix any bugs please forward the fix onto me, so I can include it in the final version.
Enjoy!
The table PossiblesTable at the end of gameplay.inc shows:
defb 3, 64, 0, 48, 88, 0, 0, 24, 0, 48, 24, 255 defb 3, 64, 0, 48, 88, 0, 24, 24, 24, 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 24, 24, 24, 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 0, 24, 24, 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 0, 24, 24, 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 24, 24, 0, 48, 24, 255Lines 3 and 5 are repeated, and if I understood it well, they should be:
defb 3, 64, 0, 48, 88, 0, 0, 24, 0, 48, 24, 255 defb 3, 64, 0, 48, 88, 0, 24, 24, 24, 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 24, 24, [color=red]0[/color], 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 0, 24, 24, 48, 0, 255 defb 3, 64, 0, 48, 88, 0, 0, 24, 24, 48, [color=red]24[/color], 255 defb 3, 64, 0, 48, 88, 0, 24, 24, 0, 48, 24, 255Now it's time to see why it doesn't the detect the real endgame situations sometimes.
Why not compile it in TG and find out if you are right
I suspect you are! :)
I tried to compile it and it complained about not having a tool to assemble. I've configured it and compiled it now, but unless I get a snapshot where the old code failed and the new doesn't, I can't prove for sure if the fix is right...
Looks like the values in columns r and b were bugged in the rest of the table, and these are the correct ones:
defb 3, 64, 0, [color=red]24[/color], [color=red]112[/color], 0, 0, 24, 24, 24, 48, 255 defb 3, 64, 0, [color=red]24[/color], [color=red]112[/color], 24, 0, 0, 24, 0, 48, 255 defb 3, 64, 0, [color=red]24[/color], [color=red]112[/color], 0, 0, 24, 24, 0, 48, 255 defb 3, 64, 0, [color=red]24[/color], [color=red]112[/color], 24, 0, 0, 24, 24, 48, 255 defb 3, 64, 0, [color=red]24[/color], [color=red]112[/color], 0, 0, 0, 24, 24, 48, 255 defb 3, 64, 0, [color=red]24[/color], [color=red]112[/color], 24, 0, 24, 24, 0, 48, 255 defb 3, 64, 0, 72, 64, 0, 0, 24, 0, 72, 0, 255 defb 3, 64, 0, 72, 64, 0, 0, 48, 0, 72, 0, 255 defb 3, 64, 0, [color=red]0[/color], 136, 0, 0, 0, 48, 0, 72, 255 defb 3, 64, 0, [color=red]0[/color], 136, 0, 0, 0, 24, 0, 72, 255r and b, are Right and Bottom values.
They are used to trigger a carry flag when added to the current pattern matching position.
So if the current position causes a carry then the current position is not valid for that pattern. ie. it goes off the screen.
The PossiblesTable contains all the possible patterns that would allow the game to continue.
If a possible pattern is found then the game can continue, it will also be used to show the player hints in the future when they get stuck.
I don't have a current gem layout table, I use the attributes display instead which is why all the patterns are offset by 24 each time.
The gem tiles are 24x24.
Yes I could optimize both the table and code to use 3 chars instead of 24 pixels, but speed is not an issue here and I prefer using the pixel values.
I must confess to not having complete debugged the tables so far.
You get to a point where your seeing things and believe whole heartedly that want your seeing is what you intended.
But computers being computers, only do as they are told and sometimes you give them the wrong instructions. ;)
Keep up the good work MetalBrain,... I expect you should have the game finished by the weekend ;)
If you keep fixing bugs at this rate I'll have to put your name on the credits. :)
I'll add more comments to the gameplay.inc file in the next release so people can understand what is going on a little more easily.
Graphics corruption happens on all tilesets, will fix that soon as well.
Thanks!
AS_Loop: call AS_CheckAll ; check all the board for any matching gem patterns AS_Cont: call c, ReplaceGems ; remove and score the matching gems jr c, AS_Loop ; keep going until no matches are left call AS_BonusAdd ; add any bonus values call CheckLevelGO ; check for next level and game over conditions [color=red]ld bc, (PointerPos) ; get the pointer position[/color] [color=red]call DrawPointer ; draw the poinet in the new position[/color] call DrawGemCursor ; draw the gem board cursor jr AS_End ; swap is completeThis fixes the graphic corruption when doing a successful swap, by updating the pointer background info. No more mixed pieces.
I think you seem to having too much fun to stop though, am I right?
Well done, MetalBrain.
Should I send you the TommyGun source so you can fix some of the bugs in that too? ;)
Waiter! There's a bug in my sauce!
Indeed :razz:
I'm sorry, I prefer Z80 asm.
ActionSwap: call EraseGameCursor ; remove the game cursor call AS_BonusReset ; reset the bonus counter ld bc, (CursorPos) ; retrieve the current cursor position ld (AS_Tile1Pos), bc ; and store it as the first tile position ld bc, (CursorPosOld) ; retrieve the the previous cursor position ld (AS_Tile2Pos), bc ; and use it as the second tile position [color=red]ld bc, (PointerPos) ; get the pointer position[/color] [color=red]call ErasePointer ; erase the pointer before swap animation[/color] call AnimateGemSwap ; animate the gem swappingThe new corruption was produced because the extra Drawpointer of the bugfix above was drawn over the new cells just swapped, but could also be partly draw over the old cell below it, so it took the cursor itself as a part of that cell below.
I'm done for today... Good luck with the complex movements fix.
I would of fixed them you know, no really i would of... eventually ;)
You'll have to tell me your thoughts on the code.
It can't be too badly coded if your fixing bugs within the first hours of downloading it. :)
Remember this game is a team effort so far, especially from RetroCoder/Mr millside, Lee_Dc and now MetalBrain too. (oh and me too, I think some of my code is in there somewhere ;))
I haven't been looking through all the code, it seems not to be too optimized (or maybe it's not optimized at all), and some design decisions seem a bit weird to me, but above all it's very well structurated and commented, so I had no problems at all finding the relevant routines to bugfix, and following them. Nice work on that!.
a) its a puzzle game and hardly exercises the cpu too much (except the scrolling)
b) there is plenty of memory available for this game to use
c) readability is more important that speed at the moment
As for design decisions, well there aren't any. Its a make it up as I go along approach, so yeah some them are a bit weird.
I'm using this as an exercise in stress testing TommyGun and finding the things in TG that piss me off and need fixing.
Like I wish I had an inbuild debugger in TG.
But that would require me to write(borrow) an emulator core and produce a debugger interface for it. Too much other stuff to do.
But want I <b>really</b> would like is a machine independent emulator core and debugger interface. You then write a machine specific component/plugin for the core to support the desired machine/hardware. eg. Speccy, CPC, C64, ZX81 etc
I suppose its similar to how MAME works in that mame supports many arcade machines through a single interface. (I think)
So anyway with this system TommyGun could then support a single debugger interface and multi machines within its IDE.
It would be as close to a Cross Platform (ie Machines) VisualStudio style development environment you would ever get.
But its a pipe dream, probably not going to happen.
Its just an idea of where TG could go in the future if the support was there for such a thing.
Thats not to say I won't at least give Fuse a try in the future to test the concept.
I'm back from my two week holiday so I'll grab the latest build on Monday and will start looking for bugs my self. Looks like the menu stuff is working well :)
played Bejueled.
Just noticed you have a deisgn doc so I`ll have to learn the rules :)
Its too easy now, let alone with diagonals as well.
Your free to add them if you like at a later date, but not at the moment until the game is complete.
The rules are pretty simple, match 3, 4, or 5 like gems in a vertical or horizontal row. easy! ;)
use fire to select a gem and fire on the second gem to do the swap.
you can use cursor keys, interface II, kempston joystick or kempston mouse.
http://www.users.on.net/~tonyt73/TommyGun/
goto Projects section
Have you looked at MESS? It's based on MAME but emulates old computers.
http://www.mess.org/
Rainbow IDE for the Tandy CoCo (and other systems) lets you assemble your code, transfer the executable to a disk image and then launch the MESS emulator with your disk already loaded and ready to test.
http://www.rainbowide.com/
I tried downloading the zip file and it appears you have taken it offline.
Unfortunately MESS's stable of emulators are not the best available. Particularly relevant to this forum, the spectrum emulator is lacking in features and accuracy.
What makes TG different is that it contains resource editors tailored for each architecture. Eg, there's an image editor, sprite editor, font editor, text editor. Code can include data from those editors and if any resource is changed, all updates are taken care of.
Unfortunately TG's not being further developed. I don't want to speak for Kiwi but I think he needs a break and will get the itch to come back and finish it off. Adding an api for 3rd party editors and data exporters would be some right-nice polish :-)
Write games in C using Z88DK and SP1
Yes I have seen MESS. I found it on source forge when looking for debuggers.
As AA says in his post above, my main concern was the speccy support is pretty lacking.
The Rainbow IDE does look impressive but $45US impressive, I'm not sure. ;)
Again as AA says, there are no resource editors???
I feel the main strength of TommyGun is the extensibility of it all.
You can use any assembler/C package and any emulator.
It will update resources automagically for you.
But sadly it doesn't write all the code for you.
The only thing I think missing from TG would be if all emulators supported a common debugger interface, and thus TG could also contain a debugger.
That way the debugger stays independent of the platform and TG would work regardless of the emulator.
Alas this is dream that just may not be possible unless I got support from the emulator authors.
AA again got something else correct as well.
I am a little tired and need a break from TommyGun and will return it to one day.
But at the moment I just stick to fixing bugs and odd feature request here and there.
I will add the API for 3rd party developers as well so people can use Visual C++ to develop plugins.
And I will also be changing the code parsers to use a custom designed scripting language that will also have built in support for creating the GUI components.
I also checked the TommyGun project links and they work fine, no files are missing.
Thanks JamesD for your input its very much appreciated.
Cheers to AA as well.
Emulator developers all seem more interested in their own emulators than a community one like MESS.
Yeah, I thought that was a bit much but it does let you try it free if you don't mind the little nag window that shows up over the button to build your project.
It does kinda limit it. There are some other environments that launch a single emulator but I don't know if any of them have a resource editor.
Send a few emails and see if you can start discussion on an open standard.
I'm sure a few comments from people to the authors encouraging this wouldn't hurt.
Btw, I'm a software engineer and I can totally understand you needing a break.
I'll go back and check. It might just be the link I tried and I'm not even sure where I got it.
No, thank you for the great software!
Just glad you like it :)
The $0million US price tag probably helps ;)