Tell me gasman do you use an IDE at all?
Like VisualStudio, Ecilpse, CodeBlocks, CrimsonEditor etc?
From the sound of things, I suspect Gasman has used a much wider variety of development environments than you have.
You seem to think of everything as 1,2,3 step solution with no way of passing information back to a previous process.
And this is complete impossible with the solution you provide because those programs are not written that with that in mind.
Rubbish. Let me give you an example: I edit my code (at least some of it) using vim. I type :make. It builds my program. If there are any errors, vim automatically jumps to the first one. I can then type :cn to get to the next error, and so on. I can do much the same if editing with emacs.
There you have two programs, communicating via (I guess) a pipe, doing exactly what you're claiming is "impossible".
This is true Rapid Application Development.
True marketing hype, anyway.
I'll bet you that if we did manage to finish this project that people like yourself would eventually use it because it would save you a lot of dev time and I bet the tools in the projects would be better than those you currently use.
With all due respect, the tools I currently use have been professionally developed over the course of the past 25 years. You're going to make better tools than that? Wow.
There is really only 2 serious groups making speccy games, Mr Cadwell and that spanish group of guys. (name?).
I presume you mean Jon Cauldwell, and the CEZ group? Obviously the two or so games I write for the speccy each year don't count?! :sad:
I use TommyGun to do the sprites on all my games, but that's as far as it goes - I don't think it's possible to write an IDE that does everything for everybody, and it's probably foolish to try to make everybody happy with one, but I'll be interested to see the outcome, so long as the sprite-editor is just as good! :)
I presume you mean Jon Cauldwell, and the CEZ group? Obviously the two or so games I write for the speccy each year don't count?! :sad:
I use TommyGun to do the sprites on all my games, but that's as far as it goes - I don't think it's possible to write an IDE that does everything for everybody, and it's probably foolish to try to make everybody happy with one, but I'll be interested to see the outcome, so long as the sprite-editor is just as good! :)
My apologies Bob and to Ian as well - because I know you guys contribute to the speccy community a lot.
I can understand that lots of people like their current tools but it is disappointing to hear some of the negative comments when someone suggests a new IDE. What is it that you like about the tools you use ? Is it the configurable output ? Ease of use ? A unique feature ? If the people on this forum could define what it is they like so much then this could be built into the new IDE. Come on guys, you may not want to use a new IDE but tell us what you love about 7up etc so we can duplicate those features.
I started my last project using the Spin assembler but the editor had a few issues and after a few changes it started to give me some AV issues. I moved my whole project over to Tommygun where I made use of some of its features. The advantage of Tommygun was that Kiwi was always willing to implement some changes and make it more enjoyable to use. A new open source IDE would allow a very flexible development environment to be created. I would also hope that once its started, developers would join in the work and help to maintain it. The problem with Spin was that updates were slow and the desired changes were not always implemented. This isn't a criticism of the Spin team, I'm just highlighting the problems created by not having open source.
I think the majority of the Spectrum community thinks too small.
Here is what makes me excited about a project like this from a Spectrum point of view:
...{removed to save space}...
The other is I'd like to see us (as Spectrum users) benefit from other retro communities by sharing code and sw easily. A spectrum-only utility could never enable that.
Ahem! AA.
I also had another idea for the tool (probably way too hard for some as well though) and its very similar to your global shared libraries and that is I wanted to have game wizards for the newbie users to make games with.
The wizards come with a software template that makes that style of game eg. a shoot'em up, a maze game or platform game etc.
Of course there would need to be a game template for every platform supported if using assembly, but if the templates where written in C and there was specialised versions of graphic and sound functions. Then only the specialised code would need to be made per platform. The game code would remain the same for all platforms. But if the asm code for the graphics, sound and input were wrapped in a C library then you could make use of the C linker to remove unneeded code at link time and only compile in the graphics, sound and input routines needed for a platform.
The wizard then sets up a todo list of tasks for the user to complete, like changing the default images, sound, map/levels etc. To personalise the game as their own.
Sure most of the games would come out the same, but thats what happens with any GameMaker style tool.
But if the game templates also allowed for customised behaviours and actions then people could with a bit extra effort make a much more individual game using the template as a base.
Also there is no reason that they can't simply use the template as a starting point to create a game and then customise it completely by using the code editor instead of the wizard tools.
As the wizard generates per C or Asm source code anyway - it just that using the Wizard view of the IDE would hide the code editor other advanced stuff - simply changing modes from Wizard to Advanced would hide the wizard stuff and show the raw IDE features for creating a game.
On the subject of porting projects.
That would be more difficult I would imagine.
Although images could be stored internally in a machine independent manor.
The images need to be rendered using a palette based on the machine they are targetting.
Just think how different the Spectrum, C64 and CPC video memory layout is.
At the sprite or tile levels they are quite different.
To convert a C64 sprite into a CPC or Spectrum image would result in a very different image if that conversion was possible at all.
So to have projects that could be instantly converted to another machine would be difficult.
But if there was a conversion wizard that highlighted the items that needed user attention then this would definitely be possible.
Sound is a little easier in that sound is basically sound on any machine.
You just need to convert it to the sound language for that machine eg: AY or SID instructions etc.
Maps and levels can be used generically on any platform as its simply a matter of data formatting.
A wizard based IDE is really only feasible with C based game templates and a suitable C based graphics, sound and input library.
I also had another idea for the tool (probably way too hard for some as well though) and its very similar to your global shared libraries and that is I wanted to have game wizards for the newbie users to make games with.
The wizards come with a software template that makes that style of game eg. a shoot'em up, a maze game or platform game etc.
Of course there would need to be a game template for every platform supported if using assembly, but if the templates where written in C and there was specialised versions of graphic and sound functions. Then only the specialised code would need to be made per platform. The game code would remain the same for all platforms. But if the asm code for the graphics, sound and input were wrapped in a C library then you could make use of the C linker to remove unneeded code at link time and only compile in the graphics, sound and input routines needed for a platform.
The wizard then sets up a todo list of tasks for the user to complete, like changing the default images, sound, map/levels etc. To personalise the game as their own.
Sure most of the games would come out the same, but thats what happens with any GameMaker style tool.
But if the game templates also allowed for customised behaviours and actions then people could with a bit extra effort make a much more individual game using the template as a base.
Also there is no reason that they can't simply use the template as a starting point to create a game and then customise it completely by using the code editor instead of the wizard tools.
As the wizard generates per C or Asm source code anyway - it just that using the Wizard view of the IDE would hide the code editor other advanced stuff - simply changing modes from Wizard to Advanced would hide the wizard stuff and show the raw IDE features for creating a game.
Brilliant Idea.
Come on guys - cut out the negativity - it's really sad to see to be honest.
Well... an ide like this, multiplatform, with all this features, an user friendly... ?what about of five years of work? (optimistic calc mode). I remember now those similar projects (smaller projects), unfinished projects at all. This is a "titanic" work, ?will you have so many free time? Ufff :roll:
P.D: The are many active speccy coders/groups, not only two. Only spanish groups : CEZ, Compiler, Octocom, Topo Siglo XXI, J.Coletas, etc (active groups).
P.P.D: Sorry for my "arapahoe" english! I hope it will be better with forum practice!
remain the same for all platforms. But if the asm code for the graphics, sound and input were wrapped in a C library then you could make use of the C linker to remove unneeded code at link time and only compile in the graphics, sound and input routines needed for a platform.
Yes but there is no need to wrap asm functions in a C anything as the linker (z88dk, sdcc, or whatever) can work equally well with pure asm functions. All the code I write, for example, is written as if it were to be called from assembler and only afterward do I add some C wrapper code to extract input parameters according to the C calling convention. I expose both the assembler and the C entry points in the libraries. This way all subroutines can be called using the z80 asm entry point from a z80 program (with registers assumed set up with input values) or the C entry point from a C program (with parameters on the stack or using some other C linking convention) or both if the subroutine is called from both assembler and C within the same program. Importantly, because the C entry point is just a wrapper around the assembler subroutine, calling the subroutine using both the C entry point (from C code) and the asm entry point (from z80 code) in the same program means only one copy of the subroutine is actually used.
Anyway the point is the linker works with pure assembler subroutines just fine, although I prefer to continue to offer both options :)
As the wizard generates per C or Asm source code anyway - it just that using the Wizard view of the IDE would hide the code editor other advanced stuff - simply changing modes from Wizard to Advanced would hide the wizard stuff and show the raw IDE features for creating a game.
The idea is a good one but also presupposes the existence of these open source libraries so that would have to be step one. I don't get quite as excited about wizards simply because they produce samish games, as you say, however I do think they would be a gateway for less experienced people to produce something and perhaps progress onto more difficult things. I do agree these wizards would make an interesting feature as plug-ins for such an ide whether people used them or not. I do think PGD is great, eg, and we have seen some map-modifying activities in these forums (Cybernoid, Bubble Bobble, ...) so there is a place for it for sure. I foresee a 3d isometric engine coming too and this sort of thing may be more ideally suited as a wizard assisted thing for designing rooms, creating scripts for characters, etc (specifically I am thinking of that 3d isometric engine released for the Oric last year). Anyway I think I would be up for helping out with a few wizards, likely more niche ones than the obvious shoot'emup. Hmmm... it may also offer the opportunity to expose people to less utilized features in available sprite engines too... that I like too :)
That would be more difficult I would imagine.
Although images could be stored internally in a machine independent manor.
The images need to be rendered using a palette based on the machine they are targetting.
Just think how different the Spectrum, C64 and CPC video memory layout is.
At the sprite or tile levels they are quite different.
To convert a C64 sprite into a CPC or Spectrum image would result in a very different image if that conversion was possible at all.
So to have projects that could be instantly converted to another machine would be difficult.
But if there was a conversion wizard that highlighted the items that needed user attention then this would definitely be possible.
Yeah I realize it would not be as simple as push a button, however what I had in mind was a 'best effort' conversion of graphics to another format similar to what the bmp2scr, etc, programs do. The user can always go back and edit things (colour, size, etc) to make them look better.
Regarding porting programs to different screen resolutions using cross-platform libraries, I agree this is not automagical either. However a nearly identical library API across platforms can take care of a lot of porting problems. I know with the SP1 engine in z88dk it will not just be a case of retargetting to another platform on the compile line, but the task of porting will not be a terribly difficult task either. And if the program is written with the idea of porting to other platforms, porting can be a relatively painless experience.
Well... an ide like this, multiplatform, with all this features, an user friendly... ?what about of five years of work? (optimistic calc mode). I remember now those similar projects (smaller projects), unfinished projects at all. This is a "titanic" work, ?will you have so many free time? Ufff :roll:
I agree, it is an ambitious project. However, the fact that the project will be centred on plug-ins means it can grow over time with many people contributing specialized bits and pieces. It is not an all or nothing project -- you start with a little something, a core, that is added to by many others over time, including many people who would not be interested in starting a large project from scratch to accomplish task A but who may be ok with taking the time to write a small plug-in to accomplish task A for an existing tool. So you may not begin with this uber-do-it-all ide but the potential is there for it to grow into something uber through the plug-in approach.
I have no idea if it will be accepted by people at large but I know I like the idea and it is worthwhile to at least try it.
Gasman mentioned earlier Visual Studio tools for GUI event code -- SymbOS has a specialized visual dialog designer that works in a very similar way for its gui widgets. This would be a perfect candidate as plug-in to highlight what can be done for retro platforms if the vision is there (both tools and z80 development).
I can understand that lots of people like their current tools but it is disappointing to hear some of the negative comments when someone suggests a new IDE. What is it that you like about the tools you use ? Is it the configurable output ? Ease of use ? A unique feature ? If the people on this forum could define what it is they like so much then this could be built into the new IDE. Come on guys, you may not want to use a new IDE but tell us what you love about 7up etc so we can duplicate those features.
(Nice icon Mr M! Who is it? :smile: )
For me TommyGun has the best sprite editor, period. I can have just about as many as I like, with as many animations frames as I like, at any size, and edit & preview them all really easily.
However, most other elements of a game tend to be very specific, and so a generic editor doesn't cover what I need. For example, the map editor produces an output of tiles + positions. But in Farmer Jack my maps used a compressed form where each tile was stored in 2 bits, and arrange in row/column order - TG doesn't support that. In my next game the map data is spread across 3 bytes per cell, but the bytes aren't consecutive - each byte is 256 apart for fast lookup - which again is something particular to that game, and TG can't support it. Even the sprite-editor isn't perfect as for splATTR I needed attribute data without pixel-data. And so I have to write my own stuff editors/whatever to handle each case as it arises.
Also, if the new IDE incorporated a better screen-editor than ZX-Paintbrush then I'd use that to do my screens, but if it's not as good I'd stick with ZX-P, since they'd be no reason to change.
As I've said before, I don't think any IDE keeps everybody happy - does anybody actually use VS.Nets bitmap editor or just use Photoshop/PaintShopPro instead...?
The image is of the lovely Sarah Beeny, she presents Property Ladder on channel 4. Just Google on the name if you want to see her :)
You mention that TommyGun doesn't give you the option to save your game tiles in your custom compressed format. I to found this to be a problem and Kiwi certainly aware it. When I spoke to him about it he wanted to produce some sort of scripted output so that TG could output the data in any format, you just defined what you wanted. I'm sure Kiwi will comment further on this over time.
As sound isn't my strong point I developed a handy routine that takes the data files that you can type into Nokia phones and converts it into data that play beeps out of the spectrum speaker. If you've ever played my Iron Sphere game you would have heard the tunes :) This would convert nicely into a plug-in.
You mention that TommyGun doesn't give you the option to save your game tiles in your custom compressed format. I to found this to be a problem and Kiwi certainly aware it. When I spoke to him about it he wanted to produce some sort of scripted output so that TG could output the data in any format, you just defined what you wanted. I'm sure Kiwi will comment further on this over time.
Yes, I think for a complete solution you'd need some kind of scriptable output, for every aspect of development. I worked around the issue for splATTR by designing huge sprites on a checked-board background, deleting the pixel-data from the output-spew, and doing a find/replace on a certain attribute value to add transparency - all of which could be done by a script.
Tell me gasman do you use an IDE at all?
Like VisualStudio, Ecilpse, CodeBlocks, CrimsonEditor etc?
If so then you know the benefits of using an IDE.
I've tried a few in the past, most recently RadRails (an Eclipse-based IDE for Ruby On Rails development). I gave up on it because its Subversion support was chronically broken, and without that it was not much more than a bloated text editor. To me, this is the hallmark of a badly-designed IDE - it reinvents everything, badly - which is why I'm keen not to see you repeat that mistake. The approach of "all plugins are built as C# modules" feels like a step in that direction... If you want to use C# modules as the primary means of extension, then that's fine - just be careful not to shut out the ecosystem of software that already exists (- and in a lot of cases, does its job much better than you can realistically hope to achieve, even with the best tool writers in the scene on board. That isn't meant as a criticism - just that, for example, Subversion integration would be very much on my wishlist for this IDE, and I'm assuming you have no desire to write a brand new Subversion client in C#...)
As I mentioned before, I do see some of the advantages of IDEs for modern software development (such as visually attaching code to GUI objects), but I'm struggling to see how they translate to 8-bit development. That might be because I'm focusing on the wrong set of benefits of IDEs, or because the 8-bit development I do is fundamentally different from everyone else's, or because I'm lacking imagination here.
AA makes some good points about what this will offer developers in real terms, which are exactly the sort of thing I was fishing for :-) I can't say I buy into all of them (I'd sooner write an application in my language of choice than a plugin in C#), but that's just personal preference. I hope I'm not coming across as overly negative - I'm just trying to steer things away from the "of course it's going to be good, it's an IDE and IDEs are wonderful" mindset and towards what it can offer me as a potential user, and how to make it useful to the biggest possible audience.
I'll bet you that if we did manage to finish this project that people like yourself would eventually use it because it would save you a lot of dev time and I bet the tools in the projects would be better than those you currently use.
I hope so. Now you know what the selling points would be for me (hint: "it has everything including the kitchen sink built in" isn't one of them), so I'm ready to be won over!
I've no idea how many retro developers here write for more than one computer. I write code for both the Spectrum and the Amstrad. Before I started using TG I had to use many different application, some easy to use, others were very poor. The advantage I found using TG is that I could continue to develop using the same environment. I've also look at developing for the Atari ST so once again, reusing TG would be a great. This to me is the big advantage of TG and hopefully the new IDE.
I've not really looked into this but I would have thought that a plug-in could be written in any .net language, not exclusively C#. If so, this would allow people with only VB, JAVA or Pascal skills to create plug-ins.
I've no idea how many retro developers here write for more than one computer. I write code for both the Spectrum and the Amstrad. Before I started using TG I had to use many different application, some easy to use, others were very poor. The advantage I found using TG is that I could continue to develop using the same environment. I've also look at developing for the Atari ST so once again, reusing TG would be a great. This to me is the big advantage of TG and hopefully the new IDE.
This is exactly what I would like to extend on with the new IDE.
TG main weakness is that its plugins are too hard for others to write.
I would like a much easier mechanism for others to extend the IDE.
I've not really looked into this but I would have thought that a plug-in could be written in any .net language, not exclusively C#. If so, this would allow people with only VB, JAVA or Pascal skills to create plug-ins.
Yep - you can use any .NET language to make a plugin.
But if it is compiled at runtime in the IDE then it would be limited to C#, J# and VB as C++ is too complex to contain in a single file - a limitation of the .NET runtime compiler as far as I have read so far.
You mention that TommyGun doesn't give you the option to save your game tiles in your custom compressed format. I to found this to be a problem and Kiwi certainly aware it. When I spoke to him about it he wanted to produce some sort of scripted output so that TG could output the data in any format, you just defined what you wanted. I'm sure Kiwi will comment further on this over time.
Yep - this was planned but I decided this new IDE was in order because I could address issues such as this one instead of trying to continue development of TG using an old compiler.
As sound isn't my strong point I developed a handy routine that takes the data files that you can type into Nokia phones and converts it into data that play beeps out of the spectrum speaker. If you've ever played my Iron Sphere game you would have heard the tunes :) This would convert nicely into a plug-in.
This is exactly the type thing that suits being a plugin and would be very easy for people to develop.
Well... an ide like this, multiplatform, with all this features, an user friendly... ¿what about of five years of work? (optimistic calc mode). I remember now those similar projects (smaller projects), unfinished projects at all. This is a "titanic" work, ¿will you have so many free time? Ufff :roll:
P.D: The are many active speccy coders/groups, not only two. Only spanish groups : CEZ, Compiler, Octocom, Topo Siglo XXI, J.Coletas, etc (active groups).
P.P.D: Sorry for my "arapahoe" english! I hope it will be better with forum practice!
Yes this project is a titanic effort - but most of the principles have been developed already in TommyGun.
I just need to fine tune them and fix the ones I need to fix.
I have learnt a lot from making TommyGun.
Sure TG probably took 3 years to get anywhere useful.
But a lot of the ideas and code is already there and we could use the ideas and algorithms in the new project.
I know of no other Image Editor that allows you to use the exact same drawing tools to create images for any computer palette.
It this kind of technique/technology that I wish to extend into the new project.
My goal is to abstract all the machine specifics into either user developed scripts (ie. custom data format for maps, images, etc) or into data files describing the translation/operation needed.
why don't you modify tommygun to support new plug-in system? it may take a while but it's quicker than to rewrite all the code from scratch.
Sometimes its better to start from scratch. It all depends on the complexity of the application and what you want to achieve. I think with TommyGun, Kiwi wants to move away from the Borland C++ environment and start something that many people can join in the development. Being open source, other people will be able to take the project forward when the rest of us are burnt out.
I work for a company that has just decided to stop developing its current suit of applications to develop a new set. In one respect I'm glad as some of the applications are still 16bit ! The down side is that the company will have nothing new to sell for several years whilst we develop the new applications. Fortunately we also make hardware so that side of the company should keep us afloat ! I don't think this is such an issue with what Kiwi wants to do. After all, its just for fun and no ones job depends on it.
It contains some of the gui mockups for Mongo.
I have called it Mongo for now. see the document for why its called that. :)
It doesn't contain a lot of programming details about the plugins as yet.
I will write a new technical document for that once I have played around with the .NET snapins interface.
Let me know what you think.
Constructive criticism is acceptable - saying this is impossible is not - bugger off if your going to be that negative.
And for all those who DON'T use IDE's and would probably never use one - no comments from you either.
Your comments are meaningless as you would never be an end user so forget it.
And sorry to the Java fans out there - this project will be using C# but as it will be open source - I see no reason why you can't port it to Java if you like.
Had a quick scan through and I've got to say I'm quite impressed with with I've read. No real criticisms but I'm not convinced about wizards to create games though I understand why it's included, guess it's just the old fashioned part of me who likes to see games created from scratch.
I do like the clean, sharp look you given it, uncluttered and clear.
I've never coded in C# before so I've got a couple of books from the library to try and get up to speed as I'd quite like to be involved. I'm a C++ person so the jump should be too difficult.
I'm writing a Spectrum Emulator which is just about at the first release stage when I sort out a couple of problems with TZX's (Which reminds me I've been away from the code for far too long, best I get take another look at it now the Christmas season is over).
And for all those who DON'T use IDE's and would probably never use one - no comments from you either.
Why not? Your IDE might be what makes someone who doesn't normally use an IDE, to use one!
Anyhoo...
The last IDE that I used for software (IBM VisualAge) allowed a really important thing to happen: to use whatever editor you liked for editing plain text parts of a project (i.e. in this case, C++ code). I would suggest not limiting the editor to C# plugins, but for text parts (I suspect writing asm in this case to glue extra bits to a project) to launch whatever text editor the user likes. Text editing shouldn't need to pass too much information to the GUI so it should be a case of the eqiuvalent of 'system("name-of-editor")' to launch a non-native text editor, and then check the return code.
I value this in an IDE extremely highly (i.e. it's a make-or-break) - perhaps because my normal day job includes everything from modifying Windows .bat files, Perl scripts, Unix shell scripts, C and C++ programs - and when I go home, a bit of PHP, Z80 asm, and more Perl. Whatever you say about vi (actually, in this case, vim) it's cross platform, language sensitive, and I find it more useful than you can believe to just have one text editor for all code editing tasks - it means only needing to remember one set of keyboard shortcuts, and one consistent behaviour regardless of the language being edited.
A plea that will probably be immediately rejected: but what about cross platform-ness? Mono is available on non Microsoft plaforms. If the GUI isn't too tightly coupled it'd be a lot easier to port.
The last IDE that I used for software (IBM VisualAge) allowed a really important thing to happen: to use whatever editor you liked for editing plain text parts of a project (i.e. in this case, C++ code). I would suggest not limiting the editor to C# plugins, but for text parts (I suspect writing asm in this case to glue extra bits to a project) to launch whatever text editor the user likes. Text editing shouldn't need to pass too much information to the GUI so it should be a case of the eqiuvalent of 'system("name-of-editor")' to launch a non-native text editor, and then check the return code.
I value this in an IDE extremely highly (i.e. it's a make-or-break) - perhaps because my normal day job includes everything from modifying Windows .bat files, Perl scripts, Unix shell scripts, C and C++ programs - and when I go home, a bit of PHP, Z80 asm, and more Perl. Whatever you say about vi (actually, in this case, vim) it's cross platform, language sensitive, and I find it more useful than you can believe to just have one text editor for all code editing tasks - it means only needing to remember one set of keyboard shortcuts, and one consistent behaviour regardless of the language being edited.
That shouldn't be too hard to support.
Actually how about this.
* Add a launch file using external editor button
* Also the application will watch for file changes and update the file if it appears in the local editor.
A plea that will probably be immediately rejected: but what about cross platform-ness? Mono is available on non Microsoft plaforms. If the GUI isn't too tightly coupled it'd be a lot easier to port.
The code will be open source - do with it what you like ;)
But porting is completely up to someone else.
I will post more comments later when I've had time to think. However, I like the Wizards idea. The whole point is to make the game creation process as painless as possible. Also, if you use wizards, you can get multiple output platforms from the same source material.
Yep that is exactly right! :)
Say for example Z88DK and SP1 compiled for all retro machines (yeah even the C64 ;) ) then we would have C based game templates and these could be re-targeted to each machine you would like your game to run on.
I want the IDE to allow for multiple target machines.
So when you compile your game if you have multiple targets then you can either choose a single target to compile and run or batch compile all of them.
The great thing about game templates is that they provide a starting point for people to create games.
Sure the lazy ones out there will simply change a few images put their name in there somewhere and call it a game and run it.
But the rest of you creative genius' can take the initial game change the game rules, modify flight patterns and implement new game elements and features then ship it as a game.
Wizards only create same-ish games if you don't modify anything or aren't given the opportunity to change things enough.
That kind of game maker is only the start of the Game Wizards I want to create.
PGD only allows you to change the game resources, but it doesn't allow you to change the game engine.
Same with most other game makers.
With Game Templates you get the game code and you are free to change it where and how you like.
Basically the templates help you make a start to your game from day one.
Instead of having to write for days and days and get nothing running for weeks.
Don't cloud your judgments using old ideas and practices.
Not a lot of feedback about the design document so I'll pass on my views.
I like the uncluttered approach of the Media Player style interface. Too many IDEs appear daunting with their multiple toolbars and endless array of buttons (most of which never get used). The Mongo interface looks clean and friendly.
What I would like to see is some information / screen "mock-ups" of the image settings. With TG you had the ability to define the size of a screen for example. I'm assuming that you would click on the little arrow on the "Images" plug-in button and be presented with a drop down menu. Would you then select "Screens" followed be a sub-menu of "New..." ? Reading further into the document you mention an "Image Manager". Is this entered first or do items just appear in here as you save things ?
I'd really like to see either some step by step images or a flow diagram on how you would go about creating a screen or a sprite. I think it would help to show the flow through the IDE to accomplish this. It could also help to iron out any potential problems.
None of this is meant as a criticism as I'm just play the role as Devils advocate. As you know form the work I did for you in testing TG I can be an evil b****** when it comes to software testing. I'm a great believer in writing product specs and test schedules before a line of code is written. Much time can be saved by doing the boring planning first :(
Have you thought about defining a development platform ? I assume you are using VS 2008 ? I don't have access to the latest "paid for" release although there are "free" versions available (I currently use 2005 Express as it integrates with XNA). I don't think you can have multiple projects in a single solution with the free versions (or is it the other way round?) This may or may not be an issue. Will the project use Source Forge as the repository ?
I don't think you can have multiple projects in a single solution with the free versions (or is it the other way round?) This may or may not be an issue. Will the project use Source Forge as the repository ?
You can, it's a little bit hidden but if you right click the solution in Solution Explorer and select Add -> New Project (or Add -> Existing Project) then it'll add the project to the same solution, just like in the full versions of VS.
I've started a thread over on the CPC Zone website about this IDE to try to get some feedback from the CPC coders. Check the following link if your interested:
Comments
From the sound of things, I suspect Gasman has used a much wider variety of development environments than you have.
Rubbish. Let me give you an example: I edit my code (at least some of it) using vim. I type :make. It builds my program. If there are any errors, vim automatically jumps to the first one. I can then type :cn to get to the next error, and so on. I can do much the same if editing with emacs.
There you have two programs, communicating via (I guess) a pipe, doing exactly what you're claiming is "impossible".
True marketing hype, anyway.
With all due respect, the tools I currently use have been professionally developed over the course of the past 25 years. You're going to make better tools than that? Wow.
I presume you mean Jon Cauldwell, and the CEZ group? Obviously the two or so games I write for the speccy each year don't count?! :sad:
I use TommyGun to do the sprites on all my games, but that's as far as it goes - I don't think it's possible to write an IDE that does everything for everybody, and it's probably foolish to try to make everybody happy with one, but I'll be interested to see the outcome, so long as the sprite-editor is just as good! :)
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
Necros.
My apologies Bob and to Ian as well - because I know you guys contribute to the speccy community a lot.
I started my last project using the Spin assembler but the editor had a few issues and after a few changes it started to give me some AV issues. I moved my whole project over to Tommygun where I made use of some of its features. The advantage of Tommygun was that Kiwi was always willing to implement some changes and make it more enjoyable to use. A new open source IDE would allow a very flexible development environment to be created. I would also hope that once its started, developers would join in the work and help to maintain it. The problem with Spin was that updates were slow and the desired changes were not always implemented. This isn't a criticism of the Spin team, I'm just highlighting the problems created by not having open source.
Ahem! AA.
I also had another idea for the tool (probably way too hard for some as well though) and its very similar to your global shared libraries and that is I wanted to have game wizards for the newbie users to make games with.
The wizards come with a software template that makes that style of game eg. a shoot'em up, a maze game or platform game etc.
Of course there would need to be a game template for every platform supported if using assembly, but if the templates where written in C and there was specialised versions of graphic and sound functions. Then only the specialised code would need to be made per platform. The game code would remain the same for all platforms. But if the asm code for the graphics, sound and input were wrapped in a C library then you could make use of the C linker to remove unneeded code at link time and only compile in the graphics, sound and input routines needed for a platform.
The wizard then sets up a todo list of tasks for the user to complete, like changing the default images, sound, map/levels etc. To personalise the game as their own.
Sure most of the games would come out the same, but thats what happens with any GameMaker style tool.
But if the game templates also allowed for customised behaviours and actions then people could with a bit extra effort make a much more individual game using the template as a base.
Also there is no reason that they can't simply use the template as a starting point to create a game and then customise it completely by using the code editor instead of the wizard tools.
As the wizard generates per C or Asm source code anyway - it just that using the Wizard view of the IDE would hide the code editor other advanced stuff - simply changing modes from Wizard to Advanced would hide the wizard stuff and show the raw IDE features for creating a game.
That would be more difficult I would imagine.
Although images could be stored internally in a machine independent manor.
The images need to be rendered using a palette based on the machine they are targetting.
Just think how different the Spectrum, C64 and CPC video memory layout is.
At the sprite or tile levels they are quite different.
To convert a C64 sprite into a CPC or Spectrum image would result in a very different image if that conversion was possible at all.
So to have projects that could be instantly converted to another machine would be difficult.
But if there was a conversion wizard that highlighted the items that needed user attention then this would definitely be possible.
Sound is a little easier in that sound is basically sound on any machine.
You just need to convert it to the sound language for that machine eg: AY or SID instructions etc.
Maps and levels can be used generically on any platform as its simply a matter of data formatting.
A wizard based IDE is really only feasible with C based game templates and a suitable C based graphics, sound and input library.
Brilliant Idea.
Come on guys - cut out the negativity - it's really sad to see to be honest.
P.D: The are many active speccy coders/groups, not only two. Only spanish groups : CEZ, Compiler, Octocom, Topo Siglo XXI, J.Coletas, etc (active groups).
P.P.D: Sorry for my "arapahoe" english! I hope it will be better with forum practice!
Yes but there is no need to wrap asm functions in a C anything as the linker (z88dk, sdcc, or whatever) can work equally well with pure asm functions. All the code I write, for example, is written as if it were to be called from assembler and only afterward do I add some C wrapper code to extract input parameters according to the C calling convention. I expose both the assembler and the C entry points in the libraries. This way all subroutines can be called using the z80 asm entry point from a z80 program (with registers assumed set up with input values) or the C entry point from a C program (with parameters on the stack or using some other C linking convention) or both if the subroutine is called from both assembler and C within the same program. Importantly, because the C entry point is just a wrapper around the assembler subroutine, calling the subroutine using both the C entry point (from C code) and the asm entry point (from z80 code) in the same program means only one copy of the subroutine is actually used.
Anyway the point is the linker works with pure assembler subroutines just fine, although I prefer to continue to offer both options :)
The idea is a good one but also presupposes the existence of these open source libraries so that would have to be step one. I don't get quite as excited about wizards simply because they produce samish games, as you say, however I do think they would be a gateway for less experienced people to produce something and perhaps progress onto more difficult things. I do agree these wizards would make an interesting feature as plug-ins for such an ide whether people used them or not. I do think PGD is great, eg, and we have seen some map-modifying activities in these forums (Cybernoid, Bubble Bobble, ...) so there is a place for it for sure. I foresee a 3d isometric engine coming too and this sort of thing may be more ideally suited as a wizard assisted thing for designing rooms, creating scripts for characters, etc (specifically I am thinking of that 3d isometric engine released for the Oric last year). Anyway I think I would be up for helping out with a few wizards, likely more niche ones than the obvious shoot'emup. Hmmm... it may also offer the opportunity to expose people to less utilized features in available sprite engines too... that I like too :)
Write games in C using Z88DK and SP1
Yeah I realize it would not be as simple as push a button, however what I had in mind was a 'best effort' conversion of graphics to another format similar to what the bmp2scr, etc, programs do. The user can always go back and edit things (colour, size, etc) to make them look better.
Regarding porting programs to different screen resolutions using cross-platform libraries, I agree this is not automagical either. However a nearly identical library API across platforms can take care of a lot of porting problems. I know with the SP1 engine in z88dk it will not just be a case of retargetting to another platform on the compile line, but the task of porting will not be a terribly difficult task either. And if the program is written with the idea of porting to other platforms, porting can be a relatively painless experience.
Write games in C using Z88DK and SP1
I agree, it is an ambitious project. However, the fact that the project will be centred on plug-ins means it can grow over time with many people contributing specialized bits and pieces. It is not an all or nothing project -- you start with a little something, a core, that is added to by many others over time, including many people who would not be interested in starting a large project from scratch to accomplish task A but who may be ok with taking the time to write a small plug-in to accomplish task A for an existing tool. So you may not begin with this uber-do-it-all ide but the potential is there for it to grow into something uber through the plug-in approach.
I have no idea if it will be accepted by people at large but I know I like the idea and it is worthwhile to at least try it.
Gasman mentioned earlier Visual Studio tools for GUI event code -- SymbOS has a specialized visual dialog designer that works in a very similar way for its gui widgets. This would be a perfect candidate as plug-in to highlight what can be done for retro platforms if the vision is there (both tools and z80 development).
Write games in C using Z88DK and SP1
(Nice icon Mr M! Who is it? :smile: )
For me TommyGun has the best sprite editor, period. I can have just about as many as I like, with as many animations frames as I like, at any size, and edit & preview them all really easily.
However, most other elements of a game tend to be very specific, and so a generic editor doesn't cover what I need. For example, the map editor produces an output of tiles + positions. But in Farmer Jack my maps used a compressed form where each tile was stored in 2 bits, and arrange in row/column order - TG doesn't support that. In my next game the map data is spread across 3 bytes per cell, but the bytes aren't consecutive - each byte is 256 apart for fast lookup - which again is something particular to that game, and TG can't support it. Even the sprite-editor isn't perfect as for splATTR I needed attribute data without pixel-data. And so I have to write my own stuff editors/whatever to handle each case as it arises.
Also, if the new IDE incorporated a better screen-editor than ZX-Paintbrush then I'd use that to do my screens, but if it's not as good I'd stick with ZX-P, since they'd be no reason to change.
As I've said before, I don't think any IDE keeps everybody happy - does anybody actually use VS.Nets bitmap editor or just use Photoshop/PaintShopPro instead...?
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
The image is of the lovely Sarah Beeny, she presents Property Ladder on channel 4. Just Google on the name if you want to see her :)
You mention that TommyGun doesn't give you the option to save your game tiles in your custom compressed format. I to found this to be a problem and Kiwi certainly aware it. When I spoke to him about it he wanted to produce some sort of scripted output so that TG could output the data in any format, you just defined what you wanted. I'm sure Kiwi will comment further on this over time.
As sound isn't my strong point I developed a handy routine that takes the data files that you can type into Nokia phones and converts it into data that play beeps out of the spectrum speaker. If you've ever played my Iron Sphere game you would have heard the tunes :) This would convert nicely into a plug-in.
Ah yes, thought so, I'm very familiar with her, er, "properties". :wink: But never seen them like that!
Yes, I think for a complete solution you'd need some kind of scriptable output, for every aspect of development. I worked around the issue for splATTR by designing huge sprites on a checked-board background, deleting the pixel-data from the output-spew, and doing a find/replace on a certain attribute value to add transparency - all of which could be done by a script.
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
I've tried a few in the past, most recently RadRails (an Eclipse-based IDE for Ruby On Rails development). I gave up on it because its Subversion support was chronically broken, and without that it was not much more than a bloated text editor. To me, this is the hallmark of a badly-designed IDE - it reinvents everything, badly - which is why I'm keen not to see you repeat that mistake. The approach of "all plugins are built as C# modules" feels like a step in that direction... If you want to use C# modules as the primary means of extension, then that's fine - just be careful not to shut out the ecosystem of software that already exists (- and in a lot of cases, does its job much better than you can realistically hope to achieve, even with the best tool writers in the scene on board. That isn't meant as a criticism - just that, for example, Subversion integration would be very much on my wishlist for this IDE, and I'm assuming you have no desire to write a brand new Subversion client in C#...)
As I mentioned before, I do see some of the advantages of IDEs for modern software development (such as visually attaching code to GUI objects), but I'm struggling to see how they translate to 8-bit development. That might be because I'm focusing on the wrong set of benefits of IDEs, or because the 8-bit development I do is fundamentally different from everyone else's, or because I'm lacking imagination here.
AA makes some good points about what this will offer developers in real terms, which are exactly the sort of thing I was fishing for :-) I can't say I buy into all of them (I'd sooner write an application in my language of choice than a plugin in C#), but that's just personal preference. I hope I'm not coming across as overly negative - I'm just trying to steer things away from the "of course it's going to be good, it's an IDE and IDEs are wonderful" mindset and towards what it can offer me as a potential user, and how to make it useful to the biggest possible audience.
I hope so. Now you know what the selling points would be for me (hint: "it has everything including the kitchen sink built in" isn't one of them), so I'm ready to be won over!
I've not really looked into this but I would have thought that a plug-in could be written in any .net language, not exclusively C#. If so, this would allow people with only VB, JAVA or Pascal skills to create plug-ins.
TG main weakness is that its plugins are too hard for others to write.
I would like a much easier mechanism for others to extend the IDE.
Yep - you can use any .NET language to make a plugin.
But if it is compiled at runtime in the IDE then it would be limited to C#, J# and VB as C++ is too complex to contain in a single file - a limitation of the .NET runtime compiler as far as I have read so far.
This is exactly the type thing that suits being a plugin and would be very easy for people to develop.
Yes this project is a titanic effort - but most of the principles have been developed already in TommyGun.
I just need to fine tune them and fix the ones I need to fix.
I have learnt a lot from making TommyGun.
Sure TG probably took 3 years to get anywhere useful.
But a lot of the ideas and code is already there and we could use the ideas and algorithms in the new project.
I know of no other Image Editor that allows you to use the exact same drawing tools to create images for any computer palette.
It this kind of technique/technology that I wish to extend into the new project.
My goal is to abstract all the machine specifics into either user developed scripts (ie. custom data format for maps, images, etc) or into data files describing the translation/operation needed.
please read this article:
http://www.joelonsoftware.com/articles/fog0000000069.html
Sometimes its better to start from scratch. It all depends on the complexity of the application and what you want to achieve. I think with TommyGun, Kiwi wants to move away from the Borland C++ environment and start something that many people can join in the development. Being open source, other people will be able to take the project forward when the rest of us are burnt out.
I work for a company that has just decided to stop developing its current suit of applications to develop a new set. In one respect I'm glad as some of the applications are still 16bit ! The down side is that the company will have nothing new to sell for several years whilst we develop the new applications. Fortunately we also make hardware so that side of the company should keep us afloat ! I don't think this is such an issue with what Kiwi wants to do. After all, its just for fun and no ones job depends on it.
I have placed a design document onto my web space.
www.users.on.net/~tonyt73/Mongo/Mongo.doc
It contains some of the gui mockups for Mongo.
I have called it Mongo for now. see the document for why its called that. :)
It doesn't contain a lot of programming details about the plugins as yet.
I will write a new technical document for that once I have played around with the .NET snapins interface.
Let me know what you think.
Constructive criticism is acceptable - saying this is impossible is not - bugger off if your going to be that negative.
And for all those who DON'T use IDE's and would probably never use one - no comments from you either.
Your comments are meaningless as you would never be an end user so forget it.
And sorry to the Java fans out there - this project will be using C# but as it will be open source - I see no reason why you can't port it to Java if you like.
I do like the clean, sharp look you given it, uncluttered and clear.
I've never coded in C# before so I've got a couple of books from the library to try and get up to speed as I'd quite like to be involved. I'm a C++ person so the jump should be too difficult.
I'm writing a Spectrum Emulator which is just about at the first release stage when I sort out a couple of problems with TZX's (Which reminds me I've been away from the code for far too long, best I get take another look at it now the Christmas season is over).
Why not? Your IDE might be what makes someone who doesn't normally use an IDE, to use one!
Anyhoo...
The last IDE that I used for software (IBM VisualAge) allowed a really important thing to happen: to use whatever editor you liked for editing plain text parts of a project (i.e. in this case, C++ code). I would suggest not limiting the editor to C# plugins, but for text parts (I suspect writing asm in this case to glue extra bits to a project) to launch whatever text editor the user likes. Text editing shouldn't need to pass too much information to the GUI so it should be a case of the eqiuvalent of 'system("name-of-editor")' to launch a non-native text editor, and then check the return code.
I value this in an IDE extremely highly (i.e. it's a make-or-break) - perhaps because my normal day job includes everything from modifying Windows .bat files, Perl scripts, Unix shell scripts, C and C++ programs - and when I go home, a bit of PHP, Z80 asm, and more Perl. Whatever you say about vi (actually, in this case, vim) it's cross platform, language sensitive, and I find it more useful than you can believe to just have one text editor for all code editing tasks - it means only needing to remember one set of keyboard shortcuts, and one consistent behaviour regardless of the language being edited.
A plea that will probably be immediately rejected: but what about cross platform-ness? Mono is available on non Microsoft plaforms. If the GUI isn't too tightly coupled it'd be a lot easier to port.
Actually how about this.
* Add a launch file using external editor button
* Also the application will watch for file changes and update the file if it appears in the local editor.
The code will be open source - do with it what you like ;)
But porting is completely up to someone else.
Yep that is exactly right! :)
Say for example Z88DK and SP1 compiled for all retro machines (yeah even the C64 ;) ) then we would have C based game templates and these could be re-targeted to each machine you would like your game to run on.
I want the IDE to allow for multiple target machines.
So when you compile your game if you have multiple targets then you can either choose a single target to compile and run or batch compile all of them.
The great thing about game templates is that they provide a starting point for people to create games.
Sure the lazy ones out there will simply change a few images put their name in there somewhere and call it a game and run it.
But the rest of you creative genius' can take the initial game change the game rules, modify flight patterns and implement new game elements and features then ship it as a game.
Wizards only create same-ish games if you don't modify anything or aren't given the opportunity to change things enough.
That kind of game maker is only the start of the Game Wizards I want to create.
PGD only allows you to change the game resources, but it doesn't allow you to change the game engine.
Same with most other game makers.
With Game Templates you get the game code and you are free to change it where and how you like.
Basically the templates help you make a start to your game from day one.
Instead of having to write for days and days and get nothing running for weeks.
Don't cloud your judgments using old ideas and practices.
I like the uncluttered approach of the Media Player style interface. Too many IDEs appear daunting with their multiple toolbars and endless array of buttons (most of which never get used). The Mongo interface looks clean and friendly.
What I would like to see is some information / screen "mock-ups" of the image settings. With TG you had the ability to define the size of a screen for example. I'm assuming that you would click on the little arrow on the "Images" plug-in button and be presented with a drop down menu. Would you then select "Screens" followed be a sub-menu of "New..." ? Reading further into the document you mention an "Image Manager". Is this entered first or do items just appear in here as you save things ?
I'd really like to see either some step by step images or a flow diagram on how you would go about creating a screen or a sprite. I think it would help to show the flow through the IDE to accomplish this. It could also help to iron out any potential problems.
None of this is meant as a criticism as I'm just play the role as Devils advocate. As you know form the work I did for you in testing TG I can be an evil b****** when it comes to software testing. I'm a great believer in writing product specs and test schedules before a line of code is written. Much time can be saved by doing the boring planning first :(
Have you thought about defining a development platform ? I assume you are using VS 2008 ? I don't have access to the latest "paid for" release although there are "free" versions available (I currently use 2005 Express as it integrates with XNA). I don't think you can have multiple projects in a single solution with the free versions (or is it the other way round?) This may or may not be an issue. Will the project use Source Forge as the repository ?
You can, it's a little bit hidden but if you right click the solution in Solution Explorer and select Add -> New Project (or Add -> Existing Project) then it'll add the project to the same solution, just like in the full versions of VS.
http://www.cpczone.net/boards/viewtopic.php?f=4&t=1662&p=12722#p12722