Small bug fixes only sorry for TommyGun.
But I have a small experimental version on the site for everyones comments on its future development course.
I haven't uploaded the update to WoS.
But if you get it and you have a faster connection that my 1K/s upload then please post to incoming on WoS. Thanks
Sorry for the lack of development - but just soooo busy at work - many apologies.
Hi Tony. When I run the .net version it throws an unhandled exception. The exe is looking for a file called "project.htm". If you choose "continue" the program then runs (or at least it does on my development machine with every version of .net going).
I'd like to see an easy way of exporting data from one project to another. For example, I'd like to extract the font from the Gems game and add it to my new game (for testing purposes....). Could all data, like fonts, maps etc, be held in their own files and referenced by the project file ?
Yeah I know about the exception but its only a demo/prototype nothing to worry about ;)
It is suppose to show a html version of the projects properties generated on the fly as the project changes. I just forgot to put the file up on the web site.
You can create a dummy project.htm file and place it in the same directory as TG.net.
As for the other feature. uummmm.
Well they could be separate files or I could add an "import from other project" feature.
You would then get the option of what things in the import project to bring into your current project.
The other good thing about this is you could import graphics from other machines and TG would do the conversion to the new machine for you.
But to do this with the existing TG you have to have 2 of them running and copy the graphics from one and then paste into the other.
Tiresome yes I know - but its the only way at present - sorry :(
As a matter of fact this kind of feature is what I would like to add to the .net TG where a project can support multiple machines and you can create an image from one machine and then duplicate it into a different machine and TG would do the color/format conversion. This means you could have 1 main reference machine that you do most of the work on and copy/duplicate the resources into the other machines you are supporting.
Regarding the .NET version - I like the idea. For such project .NET would be more flexible way for you (IDE developer). There might be voices screaming for portability, dunno how .NET can be executed on other platforms...
My other preference instead .net is QT4.
Runs on all platforms (Win, Mac, Linux) and is fairly comprehensive.
I have downloaded the SDK, but I haven't yet built an application with it.
Personally I'm more interested in the ease of creating new machines and other development aspects like the wizards to really worry about multi-platform support.
But I may create a QT4 update to match the .net version.
The time frame when this will happen?
Oh I don't know since I have had no emails to support the development and only 1 thread reply on the subject - probably never. :D
I think there are only 1 or 2 people who want TG on MacOS and not sure how many would want a Linux version.
Anyway I'm having fun improving the map editor at the moment adding the tools that don't work correctly (ie. at all) in versions 0.9.16 -> 0.9.20 :D
Oh and by the way .net can be executed on Linux using Mono or maybe even Wine.
I have just read your ideas for TG.net a couple of times and think that they are all good reasons for creating a new version of TG. I would like to see everything very configurable and data driven. I'm sure that every programmer has a different way of storing game data depending on the game and their personal preference. Then being able to transfer this data between projects would make life easier. This could allow a game to be written for multiple formats simultaneously. No more having to wait months for an Amstrad release after the initial Spectrum one. I think the idea of a game creation wizard is an interesting one. I'm not sure how often this feature would be used. Hopefully some "none" programmers may want to comment of this feature. A simplified UI would be good as there are often some items in the current TG that don't seem to fit in.
Have you posted your new ideas on any other sites ? I'm guessing that the people on this site will be happy as long as it does Spectrum related stuff.
The other benefit of moving the build to a .net solution is that I'd be happy to lend a hand.
May be you could make it open source so that the whole community could take part, although that would probably end up being mostly you with some help from me.
I have just read your ideas for TG.net a couple of times and think that they are all good reasons for creating a new version of TG. I would like to see everything very configurable and data driven. I'm sure that every programmer has a different way of storing game data depending on the game and their personal preference. Then being able to transfer this data between projects would make life easier. This could allow a game to be written for multiple formats simultaneously. No more having to wait months for an Amstrad release after the initial Spectrum one.
I am really talking about two main sets of "configurable" data here.
The first is the data used to use machines in TommyGun. This data only describes the machines so that they can be used with the machine independent tools (image/map/sound editors etc).
The second set of data is the data required by a users game. The format of this should not be under the control of TommyGun. Nor do I really want it to be. It would be best if the user describes how to convert the data stored in TommyGun into their desired format. This gives the user ultimate control of how things are put into their game.
I have 2 main ideas on this - the first since TommyGun uses xml is to use xml translation (xslt) to do it - the second is to include a scripting language in TommyGun and then the user writes their own conversion routines. Of course there would be pre-canned routines that I would include and others would be free to add theirs to the installation as they are made.
Abstracting all this data and behavior away means that TommyGun becomes a truly generic development environment where you can write software for any machine.
I think the idea of a game creation wizard is an interesting one. I'm not sure how often this feature would be used. Hopefully some "none" programmers may want to comment of this feature. A simplified UI would be good as there are often some items in the current TG that don't seem to fit in.
There are so many people out there interested in writing games that have no real experience other than to have a really cool idea and no way to implement it. The wizards would allow you to create certain game types and would allow non-programmers the ability to prototype a game.
Sure all the games would play pretty much the same depending on the game templates defined, but thats not to say they couldn't change the game code once their game is up and running.
At least it gives them a starting point - a place to conceptualize their ideas.
Even seasoned developers could use it to test sprite animations and character interactions etc.
I just would like TommyGun to be accessible to more people.
But saying that I would still like to see 2 UI's implemented -
* Easy mode - lots of wizards for the beginners
* Technical mode - no wizards, just the editors and the source code and debugger.
Have you posted your new ideas on any other sites ? I'm guessing that the people on this site will be happy as long as it does Spectrum related stuff.
No - what other sites are there that I could/should post on?
Anyway they are only ideas and may/may not ever come about.
Does retro game development really need/want something like this?
I'm just asking the question is all - testing the waters so to speak. :)
The other benefit of moving the build to a .net solution is that I'd be happy to lend a hand.
May be you could make it open source so that the whole community could take part, although that would probably end up being mostly you with some help from me.
Ian
I have no problem with open sourcing it. But your right, it would probably come down to you and me. I know you have heaps of projects on the burner and I do too, so how much could people actually rely on us to really do anything? ;) I can't even trust myself to finish the current TommyGun :(
Also if it was to be open source then it would probably be best to use QT4 so we can get MacOS and Linux builds working (plus it includes a scripting language built in and plugin support). Ideally I would love the TommyGun plugins to be built using the scripting language so they could be running on all platforms without change. :)
Map editor is now a little more usable I hope.
Added more drawing tools.
Also no .net application will probably be made.
No actual interest in it so no need to make it. :(
Probably means this version is also of limited value too; so like ZX Spin and BASin, TommyGun's future development is very likely to be over sooner rather than later.
Oh well on to other projects I guess. :(
Don't get me wrong here - I will continue to update TommyGun from time to time - but it won't be getting the lion share of my development time in the future.
Those of you that do use parts of it and may find bugs or would like to request new features - I will do my best to make the changes for you.
You can get it from the website.
If you would like to - please upload to WoS - Thank you.
Great to see the font editor working, very helpful that, saves having to define a tall 8-pixel wide sprite to do the same job.
A question though - is there any way/would it be possible to get the sprite editor to ignore the pixel data when it's dumped to a code file? Only as you'll see from the link, my current game is purely attribute-based, and so I only need that, not the pixels themselves.
[...]
There are so many people out there interested in writing games that have no real experience other than to have a really cool idea and no way to implement it. The wizards would allow you to create certain game types and would allow non-programmers the ability to prototype a game.
Sure all the games would play pretty much the same depending on the game templates defined, but thats not to say they couldn't change the game code once their game is up and running.
At least it gives them a starting point - a place to conceptualize their ideas.
Even seasoned developers could use it to test sprite animations and character interactions etc.
I just would like TommyGun to be accessible to more people.
But saying that I would still like to see 2 UI's implemented -
* Easy mode - lots of wizards for the beginners
* Technical mode - no wizards, just the editors and the source code and debugger.
[...]
This is a great idea, and I love your tool. Too bad there's no real interest from others too. I'm new in programming with graphics for the spectrum and I would love to see game wizards for beginners. (I am interested in doing a game manic miner or lode runner style). You think that creating a wizard (tutorial) for such a game would be too much? If you do it in assembly, I would like to see the code better explained - as many details as possible and no secrets. That would be great!
This is a great idea, and I love your tool. Too bad there's no real interest from others too. I'm new in programming with graphics for the spectrum and I would love to see game wizards for beginners. (I am interested in doing a game manic miner or lode runner style). You think that creating a wizard (tutorial) for such a game would be too much? If you do it in assembly, I would like to see the code better explained - as many details as possible and no secrets. That would be great!
Thanks.
Mongo could be for you then. Check out the thread.
I've had a graphics problem in the last release of TG and I still have it in this new version. I create a ZX Spectrum sprite of size 8x8, when I start to draw on the grid I don't see the pixels. If I change to a different sprite then go back to the original I then see the pixels I added. This only seems to be a problem with 8x8 images. :(
Which data are we talking about here? (please say images!)
Please let me know if this suits you bobs as I remember you also wanted this awhile back.
I haven't implemented all the interleave options so I am assuming most people use the sprite option anyway.
So please let me know if this parser works for your sprites.
Please let me know if this suits you bobs as I remember you also wanted this awhile back.
I haven't implemented all the interleave options so I am assuming most people use the sprite option anyway.
So please let me know if this parser works for your sprites.
Will do. Hoping to give it a test over the weekend.
Tony, this dll fixes the problem but now there seems to be a new (even bigger one). Any project I now open shows all the sprites as black (eg I see no pixels). As soon as you start drawing the images appear so it looks like the ink and paper are both set to black. Try looking at the sprites in the Sabre Wulf project :(
I don't see that problem in my version.
I'll make a new release tomorrow as its midnight here plus I need to be in XP to make the install package and not vista.
Ok, I have fixed the issue properly this time ;)
You can either grab the updated www.users.on.net/~tonyt73/ImageLibrary.dll from my site or you can grab the new install package.
If you are not too worried about the 8x8 sprites not drawing correctly then please just stick with 0.9.22 and save your download bandwidth.
0.9.23 only contains the 8x8 sprite drawing bug fix - nothing else.
I've taken a look at the SevenuP parser, and found some small bugs in the "Number Base" section.
One of them is a typo: Hexidecimal, and the examples are wrong, since they seem to take the 123 as an hexadecimal number before the conversion, and in the case of Decimal to hexadecimal, the hexadecimal result turns out to be the decimal value:
123 decimal is 0x291
123 decimal is %100100011
123 decimal is 0443
Wow, this Tommy Gun looks amazing. I notice on the web site that MSX is listed as a 'work in progress'. Just thought I would point out (in case you didn't know) that the TI-99/4A uses the exact same graphics chip, so, probably, once you have the MSX stuff working, the TI-99/4A stuff would come reasonably easily. Of course, the MSX and 4A had different CPUs... If you need help with the 4A technical info let me know...
Wow, this Tommy Gun looks amazing. I notice on the web site that MSX is listed as a 'work in progress'. Just thought I would point out (in case you didn't know) that the TI-99/4A uses the exact same graphics chip, so, probably, once you have the MSX stuff working, the TI-99/4A stuff would come reasonably easily. Of course, the MSX and 4A had different CPUs... If you need help with the 4A technical info let me know...
Regards
Mark.
Thanks Mark!
The MSX has been on hold for awhile.
I have all the graphics modes completed, but there are other editors required to setup the graphics and sprite tables.
This is huge task and I'm still unsure as to whether I can find the time to do this. I will try though.
And if do add full MSX-1 support I will add TI-99/A support as well.
Comments
visit www.users.on.net/~tonyt73/TommyGun
Small bug fixes only sorry for TommyGun.
But I have a small experimental version on the site for everyones comments on its future development course.
I haven't uploaded the update to WoS.
But if you get it and you have a faster connection that my 1K/s upload then please post to incoming on WoS. Thanks
Sorry for the lack of development - but just soooo busy at work - many apologies.
I'd like to see an easy way of exporting data from one project to another. For example, I'd like to extract the font from the Gems game and add it to my new game (for testing purposes....). Could all data, like fonts, maps etc, be held in their own files and referenced by the project file ?
Yeah I know about the exception but its only a demo/prototype nothing to worry about ;)
It is suppose to show a html version of the projects properties generated on the fly as the project changes. I just forgot to put the file up on the web site.
You can create a dummy project.htm file and place it in the same directory as TG.net.
As for the other feature. uummmm.
Well they could be separate files or I could add an "import from other project" feature.
You would then get the option of what things in the import project to bring into your current project.
The other good thing about this is you could import graphics from other machines and TG would do the conversion to the new machine for you.
But to do this with the existing TG you have to have 2 of them running and copy the graphics from one and then paste into the other.
Tiresome yes I know - but its the only way at present - sorry :(
As a matter of fact this kind of feature is what I would like to add to the .net TG where a project can support multiple machines and you can create an image from one machine and then duplicate it into a different machine and TG would do the color/format conversion. This means you could have 1 main reference machine that you do most of the work on and copy/duplicate the resources into the other machines you are supporting.
What do you think of the TG.net concepts?
Runs on all platforms (Win, Mac, Linux) and is fairly comprehensive.
I have downloaded the SDK, but I haven't yet built an application with it.
Personally I'm more interested in the ease of creating new machines and other development aspects like the wizards to really worry about multi-platform support.
But I may create a QT4 update to match the .net version.
The time frame when this will happen?
Oh I don't know since I have had no emails to support the development and only 1 thread reply on the subject - probably never. :D
I think there are only 1 or 2 people who want TG on MacOS and not sure how many would want a Linux version.
Anyway I'm having fun improving the map editor at the moment adding the tools that don't work correctly (ie. at all) in versions 0.9.16 -> 0.9.20 :D
Oh and by the way .net can be executed on Linux using Mono or maybe even Wine.
I have just read your ideas for TG.net a couple of times and think that they are all good reasons for creating a new version of TG. I would like to see everything very configurable and data driven. I'm sure that every programmer has a different way of storing game data depending on the game and their personal preference. Then being able to transfer this data between projects would make life easier. This could allow a game to be written for multiple formats simultaneously. No more having to wait months for an Amstrad release after the initial Spectrum one. I think the idea of a game creation wizard is an interesting one. I'm not sure how often this feature would be used. Hopefully some "none" programmers may want to comment of this feature. A simplified UI would be good as there are often some items in the current TG that don't seem to fit in.
Have you posted your new ideas on any other sites ? I'm guessing that the people on this site will be happy as long as it does Spectrum related stuff.
The other benefit of moving the build to a .net solution is that I'd be happy to lend a hand.
May be you could make it open source so that the whole community could take part, although that would probably end up being mostly you with some help from me.
Ian
Thanks for the comments.
I am really talking about two main sets of "configurable" data here.
The first is the data used to use machines in TommyGun. This data only describes the machines so that they can be used with the machine independent tools (image/map/sound editors etc).
The second set of data is the data required by a users game. The format of this should not be under the control of TommyGun. Nor do I really want it to be. It would be best if the user describes how to convert the data stored in TommyGun into their desired format. This gives the user ultimate control of how things are put into their game.
I have 2 main ideas on this - the first since TommyGun uses xml is to use xml translation (xslt) to do it - the second is to include a scripting language in TommyGun and then the user writes their own conversion routines. Of course there would be pre-canned routines that I would include and others would be free to add theirs to the installation as they are made.
Abstracting all this data and behavior away means that TommyGun becomes a truly generic development environment where you can write software for any machine.
There are so many people out there interested in writing games that have no real experience other than to have a really cool idea and no way to implement it. The wizards would allow you to create certain game types and would allow non-programmers the ability to prototype a game.
Sure all the games would play pretty much the same depending on the game templates defined, but thats not to say they couldn't change the game code once their game is up and running.
At least it gives them a starting point - a place to conceptualize their ideas.
Even seasoned developers could use it to test sprite animations and character interactions etc.
I just would like TommyGun to be accessible to more people.
But saying that I would still like to see 2 UI's implemented -
* Easy mode - lots of wizards for the beginners
* Technical mode - no wizards, just the editors and the source code and debugger.
No - what other sites are there that I could/should post on?
Anyway they are only ideas and may/may not ever come about.
Does retro game development really need/want something like this?
I'm just asking the question is all - testing the waters so to speak. :)
I have no problem with open sourcing it. But your right, it would probably come down to you and me. I know you have heaps of projects on the burner and I do too, so how much could people actually rely on us to really do anything? ;) I can't even trust myself to finish the current TommyGun :(
Also if it was to be open source then it would probably be best to use QT4 so we can get MacOS and Linux builds working (plus it includes a scripting language built in and plugin support). Ideally I would love the TommyGun plugins to be built using the scripting language so they could be running on all platforms without change. :)
Cheers,
Tony
Map editor is now a little more usable I hope.
Added more drawing tools.
Also no .net application will probably be made.
No actual interest in it so no need to make it. :(
Probably means this version is also of limited value too; so like ZX Spin and BASin, TommyGun's future development is very likely to be over sooner rather than later.
Oh well on to other projects I guess. :(
Don't get me wrong here - I will continue to update TommyGun from time to time - but it won't be getting the lion share of my development time in the future.
Those of you that do use parts of it and may find bugs or would like to request new features - I will do my best to make the changes for you.
You can get it from the website.
If you would like to - please upload to WoS - Thank you.
Cheers
Great to see the font editor working, very helpful that, saves having to define a tall 8-pixel wide sprite to do the same job.
A question though - is there any way/would it be possible to get the sprite editor to ignore the pixel data when it's dumped to a code file? Only as you'll see from the link, my current game is purely attribute-based, and so I only need that, not the pixels themselves.
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
This is a great idea, and I love your tool. Too bad there's no real interest from others too. I'm new in programming with graphics for the spectrum and I would love to see game wizards for beginners. (I am interested in doing a game manic miner or lode runner style). You think that creating a wizard (tutorial) for such a game would be too much? If you do it in assembly, I would like to see the code better explained - as many details as possible and no secrets. That would be great!
Thanks.
Also check out PGD (Platform Game Designer) which does pretty much exactly what you want.
D.
And it's pretty much excellent! Definitely my all time favourite on the Speccy (even aside from the minor glitches ;-) ).
Fixed a couple of bugs including the Text tool bug.
Added support for data to be output (parsed) in the same manner as SevenuP offers.
Get it from WoS or my site.
Which data are we talking about here? (please say images!)
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
I've had a graphics problem in the last release of TG and I still have it in this new version. I create a ZX Spectrum sprite of size 8x8, when I start to draw on the grid I don't see the pixels. If I change to a different sprite then go back to the original I then see the pixels I added. This only seems to be a problem with 8x8 images. :(
Yeah I have seen that bug before but I forgot all about it.
I was pretty sure I fixed it, but obviously I have forgotten to.
I will look into it soon.
Cheers
You can get a fix for that 8x8 bug here
www.users.on.net/~tonyt73/ImageLibrary.dll
Place it in your TommyGun\Plugins folder
No use in re-issuing the previous release for this one little bug.
Cheers
Please let me know if this suits you bobs as I remember you also wanted this awhile back.
I haven't implemented all the interleave options so I am assuming most people use the sprite option anyway.
So please let me know if this parser works for your sprites.
Will do. Hoping to give it a test over the weekend.
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
Tony, this dll fixes the problem but now there seems to be a new (even bigger one). Any project I now open shows all the sprites as black (eg I see no pixels). As soon as you start drawing the images appear so it looks like the ink and paper are both set to black. Try looking at the sprites in the Sabre Wulf project :(
I'll make a new release tomorrow as its midnight here plus I need to be in XP to make the install package and not vista.
Sorry for that Ian - will fix it asap.
No hurry as I'm not doing anything with the sprites at the moment and I don't plan to do any more programming over the weekend.
Nice to see that TG is still getting updates / bug fixes.
You can either grab the updated www.users.on.net/~tonyt73/ImageLibrary.dll from my site or you can grab the new install package.
If you are not too worried about the 8x8 sprites not drawing correctly then please just stick with 0.9.22 and save your download bandwidth.
0.9.23 only contains the 8x8 sprite drawing bug fix - nothing else.
Sorry for the any inconvience caused.
Get it from my site or from WoS.
One of them is a typo: Hexidecimal, and the examples are wrong, since they seem to take the 123 as an hexadecimal number before the conversion, and in the case of Decimal to hexadecimal, the hexadecimal result turns out to be the decimal value:
123 decimal is 0x291
123 decimal is %100100011
123 decimal is 0443
Regards
Mark.
Thanks Mark!
The MSX has been on hold for awhile.
I have all the graphics modes completed, but there are other editors required to setup the graphics and sprite tables.
This is huge task and I'm still unsure as to whether I can find the time to do this. I will try though.
And if do add full MSX-1 support I will add TI-99/A support as well.