Up-to-date tracker /creation/ program.

Up-to-date digital movie editing / creation facilities

Together with top-quality packages such as Composition and Photodesk, this software should go a long way to assisting games developers on RISC OS I would have thought.

As far as I know the only software developer addressing any of these areas and thus the only developer that I know of who is likely to help in this way is Cerilica who are developing TopModel in conjunction with Sincronia.

Surely one of the software developers with related products in these areas could assist e.g. RComp's range of music products, Clare's range of graphics products.

Certain companies will actively seek to develop software if there is sufficient demand. But of course, there's no point saying 'why don't we all ask them' because people in general seem to be naturally lethargic and apathetic. Perhaps for good reason, perhaps not.

The truth is though, not everybody has access to other platforms and perhaps would not want to use them anyway. Therefore, RISC OS needs this software development if it stands any chance of progressing in games production.

As somebody said recently on this forum, even if we can't compete with other patforms we can still endeavour to improve on RISC OS games.

It's down to the developers and the public as to whether we get this software. Games groups (i.e Artex, Paradise, VOTI, Fantasia) can only do so much.

On the 3D front TopModel is very good, but lacking animation features. Out of interest what type of resources are do you want to import ? Certain types of 3D file ?

Concerning music, well that's one area I know very little about. There used to be loads of activity on the music front. Now, like most other things, we hardly ever see anything new of any power.

Regards,

Max

Yes, the ability to import certain PC files would be a bonus especially for the more complex objects. I wasn't able to afford the accompanying TopModel CD-ROMs so I have looked on cover CDs of PC magazines and also '3d Cafe' occasionally for models but TopModel will not import many 3ds files for example which are common.
Of course, importing files is no substitute for learning to design but these models can be useful sometimes as I say.

Digital movie creation seems to be grossly undersupported as Nathan said in his article.

As for music, apart from MIDI, the most sophisticated music program suitable for games is Digital Symphony I would think. MIDI would seem to be the solution and so VOTI might have to use it eventually.

For this, ideally we need a dedicated musician!

TopModel is of course very impressive despite a few limitations and bugs. I assume you're particuarly looking foward to the TopBones when it is eventually released are you Max?

Not especially. I have no overwhelming need to do any animation at the moment. Once the TEK stuff is finished, which should be quite soon, then that may change.

Yes, the ability to import certain PC files would be a bonus especially for the more complex objects. I wasn't able to afford the accompanying TopModel CD-ROMs so I have looked on cover CDs of PC magazines and also '3d Cafe' occasionally for models but TopModel will not import many 3ds files for example which are common.

I bought at least one of the TopModel resource CD-Roms and don't really use it. IMHO The net is often a better resource - certainly there are quite a few models given away on CD-Roms these days.

Of course, importing files is no substitute for learning to design but these models can be useful sometimes as I say.

Definitely, there's not point reinventing the wheel if you don't have to.

Digital movie creation seems to be grossly undersupported as Nathan said in his article.

From the discussion, this seems to be the big hole at the moment. I wonder if there's any source code for encoding the replay format anywhere ?

For this, ideally we need a dedicated musician!

There does seem to be a real lack of musicians out there. So, if you are a musician then stand up and be counted !

I know GCC is available but something commercial with a good code insight editor would appeal more programmers that don't want to spend a day finding and downloading all the necessary files, then spend a couple of weeks getting the thing to work properly looking for and editing the appropriate setup files just to get the compiler running. Then spend another week or so downlading and setting up the libraries so that they can compile that ever appealing "hello world".

This may or may not be the story of RISC OS GCC but that's the image it has with at least some C++ users and probably most programmers that would like to move to C++.

In order to get more programmers for RISC OS I think C++ is an absolute must, BASIC and assembler aren't that appealing anymore to most people in the programming circle. C++ is also the standard when it comes to writing games on other platforms making porting games a lot easier.
Application development should be close to all C++ on a small market like RISC OS. Writing applications in assembler is a major feat and maintaining them is close to impossible. Think of the software we've lost simply because of the lack of a decent C++ development tool: Sibelius, Impression, ArtWorks and I'm quite sure that there are many more!

A good, modern C++ environment would also benefit games programming because I'm certain that a quite a few more programmers would develop that little game they've been wanting to do if it was easily available.
How many RISC OS users are either finished or are in school seeking a computer science degree that are learning ARM assembler or BBC BASIC?
All of them are either learning OBJECT ORIENTED PROGRAMMING with Java or C++ and Java being closely related to C++ and still not a feasible option when it comes to games programming there's really only one option!
Now that we're on the verge(sp?) of getting high speed processors, the need for optimized assembler routines is going to be slightly less so C++ would add to the speed of development of many games.

Acorn C/C++ stock is said to be nearly finished but who'd want to buy an environment that hasn't been developed for years and isn't likely to be in the future?
There is the option of Easy C/C++ but having read the review of it in the latest Archive, I'm not all to keen on it. An entry level compiler that you're likely to get to the limit of soon if you're serious about programming does seem like a waste of money.
According to the review those two compilers aren't very ANSI C++ friendly (Acorn's hardly at all).

Having GCC as the only option just isn't good enough, most modern programmers want their development tool ready out of the box. This is getting to be true even on Linux so there's no use for RISC OS developers to bang their heads against the wall.

Why don't the bigger software houses on RISC OS that want a C++ tool (not all want it!) form a company or a consortium to develop such a tool from scratch?
RISC OS Ltd. isn't going to do develop it, they haven't got the resources. Pace might do it but it's very unlikely.

Finally, having a good C++ development tool would make developing things like music tools, movie players and I'm quite sure TopModel wouldn't suffer much from it

Just a thought!

Gulli

Add to this list a modern C++ compiler with an IDE and a decent class library. Not to mention a good WIMP class library.

I couldn't agree more, although I'm less fussed about an IDE. The RiscGuiLib project seems to have gone a bit quiet. Alas I don't know enough about the WIMP to even attempt to contribute to something like this.

What I would like to see is some kind of statement, perhaps from RISC OS Ltd or Pace, as to the future of the Toolbox. Is the Toolbox intended to be the tool of choice? Will all required documentation and tools (ie ResEd) be made available and supported? If so then a class library based around it would be nice. If not then let's ditch it now and get a proper solution.

In order to get more programmers for RISC OS I think C++ is an absolute must, BASIC and assembler aren't that appealing anymore to most people in the programming circle. C++ is also the standard when it comes to writing games on other platforms making porting games a lot easier.
Application development should be close to all C++ on a small market like RISC OS. Writing applications in assembler is a major feat and maintaining them is close to impossible. Think of the software we've lost simply because of the lack of a decent C++ development tool: Sibelius, Impression, ArtWorks and I'm quite sure that there are many more!

Unfortunately in the (fairly) recent past various people from Pace have admitted that a full C++ compiler is probably beyond their resources. I'm also tempted more by Java because the sheer number of quality applications written in it these days is staggering. It's also incredibly easy to knock up applications in.

My personal feeling on BASIC is that, while it was great to start with, it has held the RISC OS market back for some time now. Everytime a new initiative is announced (eg a game API or something) the BASIC guys jump up with "oh please let me be able to use it from BASIC". This means either using horrid hacks or creating the API in a module and you don't even want to get me started on the limitations that imposes on the API. BASIC has it's uses but games development isn't one of them.

A good, modern C++ environment would also benefit games programming because I'm certain that a quite a few more programmers would develop that little game they've been wanting to do if it was easily available.

It would certainly make porting easier. In another thread there's a comment about the projects going on over in coderscauldron.com and why not use OpenGL? Well OpenGL would be great but if you can't even compile the code you're porting because the C++ compiler isn't up to it then you're not much better off.

Java being closely related to C++ and still not a feasible option when it comes to games programming there's really only one option!

Actually there are some really impressive software rendering only engines in Java these days. Put it on top of an API and it's not bad. I've even seen a Quake viewer written in it (and that was a few years ago).

Now that we're on the verge(sp?) of getting high speed processors, the need for optimized assembler routines is going to be slightly less so C++ would add to the speed of development of many games.

I couldn't agree more. I've felt this for years. I can write ARM code but I don't see it as being particularly productive.

Why don't the bigger software houses on RISC OS that want a C++ tool (not all want it!) form a company or a consortium to develop such a tool from scratch?

I don't believe it needs building from scratch. - it could be built around GCC. It needs a decent installer, a decent set of libraries and the capability to do things like build RISC OS modules. Having said that GCC isn't as close to the ANSI C standard as Norcroft C is.

Finally, having a good C++ development tool would make developing things like music tools, movie players and I'm quite sure TopModel wouldn't suffer much from it

Well they wouldn't magically appear but there might be more incentive to actually write the code.

As important as C++ is I also believe a proper RAD environment is needed. Delphi anyone?

In my opinion what we need /now/ is software improvements. I'm perfectly happy to work with BASIC and assembler to program and I enjoy using both greatly.
I am in the process of writing a game using these languages, so I have a fairly clear idea what I most need.
Sunburst was written in the same way. Exodus was written in ARM and the only argument Artex made for C was that it would enable portability to other platforms.

The environment exists on RISC OS to create high quality games i.e assembler, BBC BASIC and the WIMP. Admittedly, the programming of games development applications may well benefit from object orientated programming but what I need is the ability to create music and graphics which I can then add using BASIC or assembler.

Speaking personally I don't really want to port games from other platforms, I'd prefer to make originals and I think BASIC and assembler are fine for this especially given the situation with faster machines being promised.

If it helps application development then I hope C development is embraced but lets not neglect the environment which comes as standard with RISC OS machines.

I'm sorry but I do not agree with there not being a good enough environment for games coding.

In my opinion what we need /now/ is software improvements. I'm perfectly happy to work with BASIC and assembler to program and I enjoy using both greatly.
I am in the process of writing a game using these languages, so I have a fairly clear idea what I most need.
Sunburst was written in the same way. Exodus was written in ARM and the only argument Artex made for C was that it would enable portability to other platforms.

The environment exists on RISC OS to create high quality games i.e assembler, BBC BASIC and the WIMP. Admittedly, the programming of games development applications may well benefit from object orientated programming but what I need is the ability to create music and graphics which I can then add using BASIC or assembler.

Software improvement is an excellent reason a good C++ compiler is needed and needed soon. WIMP application development in assembler isn't realistic anymore, many companies have tried and given up, I again offer Sibelius and Computer Concepts as high profile players in the market lost because Acorn didn't come up with a useable C++ compiler.
You're not going to develop a decent tracker or 3D modelling software in BASIC, it's possible but absolutely useless. Even with higher power processors it's never going to get anywhere near an application created in C++ when it comes to speed which is a very important factor in both tracker and graphics software.

Then there's the more and more important issue of movie players that are available on other platforms. These need to be ported and I assure you, they're not written in BBC BASIC or ARM Assembler! There are bound to be several AVI and MPEG players out there written in C++ that would require only minimum changes to work on RISC OS. The only other option is to write them from scratch in assembler - not a tempting option for someone that requires a movie player now!

Speaking personally I don't really want to port games from other platforms, I'd prefer to make originals and I think BASIC and assembler are fine for this especially given the situation with faster machines being promised.

Here you're forgetting two very related and VERY important factors. Developing a game/application is a whole lot easier and less time consuming in C++ than in assembler plus the access you'd have to all sorts of libraries, techniques, problems already solved and examples that on most websites and books are written in C++. Why on earth should the lone programmer that's still struggling out there not have access to this instead of having to re-invent the wheel several times while writing a small tetris clone?
Time is an enemy of anyone writing any kind of program for RISC OS since most developers are doing it in their spare time. C++ development is significantly faster than any assembler development and as I said before, allows the programmer to search the internet for solutions to particular problems with complete code from sites like www.flipcode.com and www.gamasutra.com to name only two.

If it helps application development then I hope C development is embraced but lets not neglect the environment which comes as standard with RISC OS machines.

The trouble is everything else has been neglected because of the love for BASIC and assembler (I like both but both have their severe limits).
RISC OS can't afford to lose more major players because of this obvious and serious lack of a development environment that's up to date and in line with what's going in the world around us. RISC OS people need to wake up and realise that RISC OS has stood still for many years because too many have been unwilling to admit that Windows, MacOS and now Linux as well passed us a few years ago and RISC OS users and developers continue to hang on to that long lost fame for innovation and originality. Now we're just lagging way behind!

In my opinion even RISC OS itself should be completely rewritten in C++ in order to make upgrades and updates easier. An operating system that has a new version every three or four years isn't going anywhere but down!

I couldn't agree more. IMHO the one thing that RISC OS needs more than anything else is a decent, free, easy to use development environment. The closer this get to an IDE, the better.

I'm a coder by profession, but I've given up trying to write software (in C++) for RISC OS - it's too much like hard work. I'm sure there are plenty of others out there like me.

If you want software, give people the environment to write the software.

There must be someone out there that can create an environment based around gcc.

Then somebody replied saying BASIC and ARM are no good for games writing but this has been demonstrated several times.

I couldn't agree more. IMHO the one thing that RISC OS needs more than anything else is a decent, free, easy to use development environment. The closer this get to an IDE, the better.

This wouldn't necessary have to be free - if it's available for a reasonable price people will buy it. The main issue is get it out ASAP, free or commercial - it's needed NOW.
I know money is always an object but say 200 UKP is hardly going to break many banks but could really be an incentive for someone to create this application.
We have to start getting it into our heads that we need more commercial applications and we need a commercial development tool from someone who's going to keep developing it. This is what many people in the Linux world have discovered, in order for Linux to grow some money must start changing hands soon, cash flow in the market is needed. Same applies to RISC OS. If it's not financially viable to write software for the OS, software development will slowly die and the platform with it!

I'm a coder by profession, but I've given up trying to write software (in C++) for RISC OS - it's too much like hard work. I'm sure there are plenty of others out there like me.

If you want software, give people the environment to write the software.

It's good (not really though) to read this, people need to start take notice and listen to the complaints from the developers - if they leave there'll be nothing left!

There must be someone out there that can create an environment based around gcc.

TCR started such a development but according to Artchie, the team founder, all work has stopped due to lack of interest by programmers. Hardly anyone has offered any help with that project. That unfortunately is the usual problem with these free projects for RISC OS, someone gets a good idea, can't quite finish it off by him/herself and tries to build a team. Many are interested but no one seems to be able to offer any real help. Of course there are large and excellent exceptions but those are few and far between.

Maybe APDL or whoever now owns and develops Easy C/C++ is reading this and sees a possibilty A real software development tool is needed!

I'm quite certain that RISC OS Ltd. and Pace Ltd. would be willing to help out quite a bit with development of a commercial development tool for RISC OS, after all they'd hardly be losing much doing that!

Of course applicaion development will benefit from a C-style langauge being available in up-to-date form. My major point was I am okay with assembler and BASIC and rightnow I need improved software. I don't need to speculate on what should be done, just the upgrades.

The problem is that the software you want (movie players etc) are better written in C/C++. It can be done more quickly, porting is a possibility and the performance loss compared to hand written ARM isn't as big as people would like to believe.

Then somebody replied saying BASIC and ARM are no good for games writing but this has been demonstrated several times.

That would be me then and it's a sign of my frustration that, in the past, when I've been involved in things like 3D APIs someone comes along and says "Oh but I just have to be able to use it from BASIC". Why? BASIC is hardly suitable for writing high-speed 3D apps. Yes there are modules but then you only have to read up on the problems with making this work efficiently on Coders Cauldron to see why it isn't really an option.

Furthermore (and my biggest gripe) is that to make an API / engine really simple to use it helps if you can register callback handlers with the API for enumerating data or allowing an application to alter the processing of an object. I know the GameSuite modules had a technique for doing this but the overhead compared to a simple call through a function pointer would be awful.

If someone can show me how to "simply" callback an ARM, C or BASIC function in user space from within a module then perhaps I'd be more willing to accept BASIC as an appropriate language. Note the "simply". I don't see supporting BASIC as being worthwhile enough to spend a week developing a solution.

Put another way, yes BASIC and ARM have been successful, but then who has picked up StrongEd, or TAG, or any of the other, mostly ARM code applications where the source code has been released?

I'd just like to see the development software updated -whatever it's written in!

If someone can show me how to "simply" callback an ARM, C or BASIC function in user space from within a module then perhaps I'd be more willing to accept BASIC as an appropriate language. Note the "simply". I don't see supporting BASIC as being worthwhile enough to spend a week developing a solution.

I may have said it before, but this is my 'simple' method. The user calls an API routine. The API does some stuff. The API realises it needs user input, so it returns from the function (Back to the user's code), with a special reason code (like a WIMP block). The user does it's stuff, then calls a return function which makes the API pick up where it left off.

It's not too easy to program on the API side, but should be quite possible.

[I may have said it before, but this is my 'simple' method. The user calls an API routine. The API does some stuff. The API realises it needs user input, so it returns from the function (Back to the user's code), with a special reason code (like a WIMP block). The user does it's stuff, then calls a return function which makes the API pick up where it left off.

It's not too easy to program on the API side, but should be quite possible.

I know because this is what GameSuite does for processing objects. The real problem with this kind of approach is the overhead of doing so - bear in mind that you're polling a SWI on what could be very fine grained events. I guess you could set a kind of poll mask for general events and, say, object events to prevent the module from returning when it doesn't have to.

It just seems all rather contrived - especially when you consider most game loops - everytime you return from the SWI handler the engine will have to keep state as to where it got up to (although I guess the main processing loop could consist of a table of function pointers which is simply cycled through).