http://www.cerilica.com/topmodel/index.htm

Cheers,

Mike

And precisely who is going to do this? For years and years we've had talk of 3D engines being generally availabe (anyone recall TAG et al?) but nothing has come of it. Everyone knows that a decent 3D library is needed, but finding some coder proficient enough to code the stuff and not tempted to go and earn some real money (TM) is rather difficult.

TAG 1 is generally available. It's on the TBA CD from RComp. It's getting on a bit though.

Both engines and design packages would be greatly helped by a usable (ie hardware accelerated) API. OpenGL gets my vote. I've done a bit of 3D programming in the past but, quite frankly, I can't be bothered spending the time building up the routines in optimised ARM code when I can more easily use OpenGL / Direct3D on other platforms.

OpenGL would also open up the possibility of ports from linux although I hasten to add it would still not be easy to do the port so people shouldn't expect a huge glut of them to magically appear.

Its one of the wierdest programs ever, but is suprisingly capable, and when development stopped on Top Model I migrated to this on Windows.

Writing a program of equivalent capability exclusive to the RISC OS scene I seriously doubt could ever be considered.

On the music side, RO land has been left way way behind unfortunately. With Apple now owning emagic, and Pinnacle owning Steinberg the sequencer world has really turned into a 2 horse race. Modern sequencers are (in my view as a programmer) harder to implement than a good 3D graphics program.

I think you meant more soundtrackery style stuff though. Personally I think there needs to be a decent sound editor first, then a program like Acid.

I've been a RISC OS lover for years and years now, but I really think its time has unfortunately passed. The best strategy here is to make porting tools from Linux as easy as possible, maybe things like a GTK+ port for getting the Gimp running. My hope is that some day soon someone will create a desktop for Linux that captures what was good about RO. I hate to be overly pessimistic, but I struggle to get enthusiastic about the potential in the RO market anymore, I've been in it since 89, and have seen too many hopes fade along the way. My experiences with TopModel were in a sense the last straw, and thats not to disrespect the developer, since theres only so much he could do, with his time more profitably spent elsewhere.

Writing a program of equivalent capability exclusive to the RISC OS scene I seriously doubt could ever be considered.

Currently it would be a labour of love because it certainly wouldn't pay for itself.

On the music side, RO land has been left way way behind unfortunately. With Apple now owning emagic, and Pinnacle owning Steinberg the sequencer world has really turned into a 2 horse race. Modern sequencers are (in my view as a programmer) harder to implement than a good 3D graphics program.

I agree. I recently obtained a cheap sequencer for my PC and it blows away the last version of StudioSound. While I still use my RS for sampling and midi sequencing all the audio get transferred to the PC for final sequencing and mixing. It's not just a question of software either, the PC can manipulate the audio much more quickly. Even if a top notch sequencer appeared for ROS tomorrow I doubt I'd go back.

I don't agree that writing a good sequencer is any more difficult than writing a good 3D editor. They're very different challenges.

I've been a RISC OS lover for years and years now, but I really think its time has unfortunately passed. The best strategy here is to make porting tools from Linux as easy as possible, maybe things like a GTK+ port for getting the Gimp running.

I believe Peter Naulls has an in progress port of GTK+ and has apparently got the GIMP running in some form on RISC OS.

http://www.chocky.org/unix/screenshots.html

My hope is that some day soon someone will create a desktop for Linux that captures what was good about RO. I hate to be overly pessimistic, but I struggle to get enthusiastic about the potential in the RO market anymore, I've been in it since 89, and have seen too many hopes fade along the way. My experiences with TopModel were in a sense the last straw, and thats not to disrespect the developer, since theres only so much he could do, with his time more profitably spent elsewhere.

I also wonder if development stopped because the author realised he could achieve his goals much more easily on other platforms. It's a point that a lot of RISC OS advocates really hate to hear but development of a lot of stuff is far easier on Windows and linux than it is on RISC OS. Given that most RISC OS developers are part time then it has to be easy to achieve the desired results.

One thing I still can't believe is the sheer advocation for writing software with reams of ARM code in it. No sooner had the Iyonix been announced than people were discussing XScale specific optimisations. Why? It's just not a productive way to write software. Perhaps it isn't helped by the fact that RISC OS APIs are inherently at odds with the APCS standard used by compiled languages meaning that you have to dip into ARM code or write a module to do certain things. This is practically unheard of on other platforms. RISC OS users take to mick out of Visual Basic and the like, but those languages are the reason why Windows leads the application market.

Rant over

Nigyeb - the future has surely just begun for RISC OS! I 've been as disappointed as most with the lack of progress but I'd never give it up as long as there is a single chance that there is a future.

I mean I'd like to just be able to create some freeware retro-platformers or graphic adventures but there isn't the software to even go beyond anything but rudimentary stick man almost animation. It's pretty frustrating.

[Edited by andreww at 11:42, 24/1/2003]

... Perhaps it isn't helped by the fact that RISC OS APIs are inherently at odds with the APCS standard used by compiled languages meaning that you have to dip into ARM code or write a module to do certain things. This is practically unheard of on other platforms...

I was under the impression that it was universally the case that you could do things in machine code that you couldn't do (efficiently) in higher level languages. Like reading the carry flag in C, f'rinstance.

I mean I'd like to just be able to create some freeware retro-platformers or graphic adventures but there isn't the software to even go beyond anything but rudimentary stick man almost animation. It's pretty frustrating.

What sort of thing are you looking for?<br>
I mean, what are the features which would make a graphic artist's life easier?

Of course 3D animation software like TopBones would be ideal but as I say we'll have to wait to see what is released.

I was under the impression that it was universally the case that you could do things in machine code that you couldn't do (efficiently) in higher level languages. Like reading the carry flag in C, f'rinstance.

I agree that there are certain things that you will always be able to do more efficiently in assembly language, that's not the point I'm making. The point I'm making is that I don't particularly care for writing the ultimate in efficient code if it takes me ten times longer to do it. Andrew (half jokingly I suspect) pointed out that ruthless marketing has a lot to do with Window's lead in the applications arena. However marketing isn't worth anything if the applications don't actually exist.

The only reason I sit here and moan is because I do actually try to write code, but with my day job consisting of developing on Windows and linux, I find that if I can't do something quickly then I usually can't be bothered (or I write it on a different platform). I'm not an ARM code whiz and I don't enjoy spending my time writing it. Having said that I did spend the majority of this weekend with my head in the PRMs (getting considerably frustrated)

The only reason I sit here and moan is because I do actually try to write code, but with my day job consisting of developing on Windows and linux, I find that if I can't do something quickly then I usually can't be bothered (or I write it on a different platform). I'm not an ARM code whiz and I don't enjoy spending my time writing it. Having said that I did spend the majority of this weekend with my head in the PRMs (getting considerably frustrated)

Liar! You're skiving again aren't you Lee?

Perhaps it isn't helped by the fact that RISC OS APIs are inherently at odds with the APCS standard used by compiled languages meaning that you have to dip into ARM code or write a module to do certain things.

I don't know C, but couldn't you write some sort of one-size-fits-all macro to do whatever it is?

The APCS standard is basically that fns are passed first 4 values in regs, with the rest stacked, isn't it? That is as much as I understand about it, anyway.
So the problem is you want to do an SYS call with more than 4 arguments?
So what you want to do is write something simple like
SYS"OS_SomeRandomCall",0,1,2,3,4,5,6

which gets all snarled up in C somehow?

I'd have thought there would be/you could make some funky black box you could just shove all these arguments into.

Character animation like laying out and overlaying the frames in boxes on the desktop and allowing you to preview perhaps and there must be software out there on other platforms with many time-saving or handy features. I was speaking to David McEwen and he said there was software on the Amiga to assist 2D animations in game sprites.

Well, I dunno, I use paint.
I think you mean that when you have a sequence of sprites you cannot adjust them in real-time?
I wouldn't have thought it would be much harder than writing paint to write a program which would let you edit a series of sprites, all of the same size in one wide window, and have an animated window at the same time.
Don't think I'm about to write one now (Desktop programming is no longer impossible for me but it is very difficult). But at least I appreciate that this would fill a niche.
When I want a certain function I usually hack one together in Basic, outside the desktop. Quite a lot of the artwork I've done for a project not -quite- abandoned yet has been processed in such a manner at some stage. Perhaps you could knock up an editor with the functions you desire. If you don't worry about making things pretty you can make a tool to enable generation of your data fairly quickly.

I'm with you on the speed-of-writing thing. Up to a point. Time-critical things should always be optimised, IMHO.

Couldn't agree more. The only thing is there's often a lot more to be gained from choosing a better algorithm than simply writing in assembler.

I don't know C, but couldn't you write some sort of one-size-fits-all macro to do whatever it is?

I suspect so - see later.

The APCS standard is basically that fns are passed first 4 values in regs, with the rest stacked, isn't it? That is as much as I understand about it, anyway.

That's about the size of it.

So the problem is you want to do an SYS call with more than 4 arguments?
So what you want to do is write something simple like
SYS"OS_SomeRandomCall",0,1,2,3,4,5,6

which gets all snarled up in C somehow?

I'd have thought there would be/you could make some funky black box you could just shove all these arguments into.

Nope, the particular problem is that I want to write a voice generator and a voice generator must implement an interface that is not APCS compliant. Furthermore AIUI C code can't be run in certain processor modes (only usr and svr??) so the veneer has to switch the processor mode, set up the C runtime, call the C code in an APCS compliant manner, and then clean up when the C code returns.

Now at this point I expect lots of people to jump in and shout that CMHG will generate the veneers for me if I use such and such flag (ie generate your "generic macro". The problem I have with this is that the people who can tell me what I need to know seem to have figured it out by looking at CMHG's assembler output. The documentation on exactly what veneers CMHG can create, when they should be used and what the C code should return, is woefully inadequate. Then again perhaps I'm just not matching up the appropriate parts of the PRMs with the C manuals.

A further problem is that to exploit CMHG I have to write a module, and there are plenty of people out there who will also argue why "novices" such as myself shouldn't be writing modules

Now if I look in the MSDN I find that, lo and behold, DirectX 8 offers a fairly convenient API for what I want to do. Furthermore the documentation is (reasonably) thorough, complete with step by step example code. Not a mention of assembler anywhere either.

Anyway, before I get mega flamed, I think I've worked out what I was misunderstanding in the PRMs so hopefully I'll make a bit more progress this weekend.

I'm with you on the speed-of-writing thing. Up to a point. Time-critical things should always be optimised, IMHO.

Couldn't agree more. The only thing is there's often a lot more to be gained from choosing a better algorithm than simply writing in assembler.

Heh, to me that is optimising as well. The first stage is to get the best possible algorithm you can in your high level language of choice. The next stage is to optimise the algorithm (ie convert to naive, 'get it working' machine code). Only then should you attempt to optimise the machine code, when everything else is working, and you are sure it is taking up too much time.

Although I do sometimes have problems actually making myself do things this way..

Nope, the particular problem is that I want to write a voice generator and a voice generator must implement an interface that is not APCS compliant. Furthermore AIUI C code can't be run in certain processor modes (only usr and svr??) so the veneer has to switch the processor mode, set up the C runtime, call the C code in an APCS compliant manner, and then clean up when the C code returns.

By a funny coincidence, I've been looking at doing sound recently. It took the best part of this Saturday to go from silence to a Real Bronx Cheer, and finally to get a pure tone. I'm not entirely confident I understand it fully yet because I don't always get what I expect when I add 2 different waveforms, but I'm not too worried.
This was a linear sound generator BTW ie 16 bit. I don't think 8bit is much different, apart from being logs.

If you want I can send you my code (Basic and ARM), such as it is.

I guess the reason it is not APCS compliant is because they wanted it to go as fast as possible. There are all sorts of warnings about timing problems.

One thing is that IIRC there was a note about not changing to certain processor modes - this might be a potential gotcha. Also the recommended return was MOVS PC,R14 so I dunno how to make it 32bit compliant.

I don't know even what CMHG is, but this sort of thing is why I haven't learnt C, it just looks like such a tw@t to use.
Anyway, this is really writing to the metal; it is not really comparable with DirectX, is it?
I guess the thing is that on PCs sound is such a mess that they really really needed an API, because the sound cards were diverse and incompatable.

Heh, to me that is optimising as well. The first stage is to get the best possible algorithm you can in your high level language of choice. The next stage is to optimise the algorithm (ie convert to naive, 'get it working' machine code). Only then should you attempt to optimise the machine code, when everything else is working, and you are sure it is taking up too much time.

Yeah but often you don't have to get down to assembler

By a funny coincidence, I've been looking at doing sound recently. It took the best part of this Saturday to go from silence to a Real Bronx Cheer, and finally to get a pure tone. I'm not entirely confident I understand it fully yet because I don't always get what I expect when I add 2 different waveforms, but I'm not too worried.
This was a linear sound generator BTW ie 16 bit. I don't think 8bit is much different, apart from being logs.

Now I'm getting scared. What I'm trying to put together is a 16bit WAV player but at this point I haven't even got as far as making a sound.

One of the things that confused the hell out of me was the documentation on linear handlers and voice generators because at first glance the linear handler looks like it could generate the sound itself.

I realise that SoundCon and PlayIt can do what I want (and THSound) but I've specific reasons for wanting to do it myself.

If you want I can send you my code (Basic and ARM), such as it is.

Now I would be stupid to ignore an offer like that, so if you wouldn't mind I'd be very much obliged.

I guess the reason it is not APCS compliant is because they wanted it to go as fast as possible. There are all sorts of warnings about timing problems.

I think the answer is more simple. The OS came along before the compilers so the APCS didn't exist. Then they realised the they couldn't conform to RISC OS APIs and do efficient method calls in a compiled language. It's probably the same on Windows but the support for compiled languages is better so people don't have to use assembler to interface with certain features of the OS.

One thing is that IIRC there was a note about not changing to certain processor modes - this might be a potential gotcha. Also the recommended return was MOVS PC,R14 so I dunno how to make it 32bit compliant.

Oh I'm not too worried about 32bit compliance for the moment

I don't know even what CMHG is, but this sort of thing is why I haven't learnt C, it just looks like such a tw@t to use.

Ok, CMHG generates module headers and some module support code from a script file that can be linked to C code compiled using a specific compiler option because you can't easily create a module header directly in C. It also creates veneers that ensure the C runtime is setup correctly and so forth before it calls your C functions to actually perform whatever needs doing.

Anyway, this is really writing to the metal; it is not really comparable with DirectX, is it?
I guess the thing is that on PCs sound is such a mess that they really really needed an API, because the sound cards were diverse and incompatable.

Well DirectX simply provides a hardware abstraction which allows different hardware to be used without altering the code. However DirectX just defines the API, the drivers are implemented by the hardware developers so take full advantage of the hardware. Making a DirectX call is kind of like calling a SWI on RISC OS. On the Iyonix the SpriteOp SWIs have probably been reimplemented to use the GeForce card directly and it's the same for DirectX. In a sense it is programming to the metal but in a way that doesn't break your code when the hardware changes.

Besides they've all got 2Ghz+ processors now so the odd wasted cycle isn't really noticable

Well, I dunno, I use paint.
I think you mean that when you have a sequence of sprites you cannot adjust them in real-time?
I wouldn't have thought it would be much harder than writing paint to write a program which would let you edit a series of sprites, all of the same size in one wide window, and have an animated window at the same time.
Don't think I'm about to write one now (Desktop programming is no longer impossible for me but it is very difficult). But at least I appreciate that this would fill a niche.
When I want a certain function I usually hack one together in Basic, outside the desktop. Quite a lot of the artwork I've done for a project not -quite- abandoned yet has been processed in such a manner at some stage. Perhaps you could knock up an editor with the functions you desire. If you don't worry about making things pretty you can make a tool to enable generation of your data fairly quickly.

I'd need to see what kind offeatures are available in some of the packages I've been told about. It's hard to see that they wouldn't make life a huge lot easier than the current situation.

It's a major, major job animating game sprites if you want them to look half-decent.

Yeah but often you don't have to get down to assembler

Now I'm getting scared. What I'm trying to put together is a 16bit WAV player but at this point I haven't even got as far as making a sound.

One of the things that confused the hell out of me was the documentation on linear handlers and voice generators because at first glance the linear handler looks like it could generate the sound itself.

Basically the sound generator does create the sound itself. Well it supplies the data anyway.
The 8 bit system uses logs.
loga+logb=log(a*b) not log(a+b)
I guess this is why you have multiple channels.

The 16 bit system it is linear so there is only one input for each side, you can just add all your samples together (providing you don't exceed the limit).
That was what I understood, anyway.

If you want I can send you my code (Basic and ARM), such as it is.

Now I would be stupid to ignore an offer like that, so if you wouldn't mind I'd be very much obliged.

Well DirectX simply provides a hardware abstraction which allows different hardware to be used without altering the code. However DirectX just defines the API, the drivers are implemented by the hardware developers so take full advantage of the hardware. Making a DirectX call is kind of like calling a SWI on RISC OS. On the Iyonix the SpriteOp SWIs have probably been reimplemented to use the GeForce card directly and it's the same for DirectX. In a sense it is programming to the metal but in a way that doesn't break your code when the hardware changes.

I suppose it would be possible to write a module which would furnish SYS calls to manage the sound system. Quite what the best interface would be I don't know.

I'd need to see what kind offeatures are available in some of the packages I've been told about. It's hard to see that they wouldn't make life a huge lot easier than the current situation.

It's a major, major job animating game sprites if you want them to look half-decent.

To be honest I find this response amusing.
Perhaps if you were to nail down exactly what it was you wanted - or preferably discussed it in great detail in an appropriate forum (like the graphics section of the icon bar) - you might have a chance of persuading a programmer to make it for you.

But to be so vague as to not know what the features you want are, and not even bother thinking about it... well.
You say animating sprites is a major job, and so it can be. But so is programming. And so is designing a suitable and user-friendly interface. Any even slightly experienced programmer will tell you that you should have a good plan before you start the code. For you to treat this so casually suggests to me that you don't appreciate the effort involved.

probably not - if you code in C this is basically done for you.

Yep, and it's quicker to develop in. Also I write a lot of cross platform code so assembler is often out of the question unless I want to create abstraction layers.

The sound stuff I want to do is purely RISC OS though.

Why does this scare you?

I was mucking around. When you said you were doing exactly the same thing I heard the music from "The Twilight Zone" in my head

Basically the sound generator does create the sound itself. Well it supplies the data anyway.
The 8 bit system uses logs.
loga+logb=log(a*b) not log(a+b)
I guess this is why you have multiple channels.

The 16 bit system it is linear so there is only one input for each side, you can just add all your samples together (providing you don't exceed the limit).
That was what I understood, anyway.

I must admit it was my first impression to. However then I read a bunch of usenet messages saying that the 16bit sound system was exactly the same as the 8bit one except it took linear data. That was a major point of confusion because suddenly it seemed I had to start writing voice generators as opposed to just replacing the linear handler. It didn't help my poor confused mind to see that SoundCon plays back 16bit sound in a voice generator.

Just emailed it to the address in your profile.
Don't expect too much from it, it is fairly basic.

Thanks a lot. I've had a quick look and "fairly basic" is exactly what I need. I'll take a closer look when I get home but it has already suggested I was on the right track before I got confused with the differences between the 8bit and 16bit systems.

I suppose it would be possible to write a module which would furnish SYS calls to manage the sound system. Quite what the best interface would be I don't know.

Well technically it's already there. That's why the RiscStation and Iyonix can provide sound through non-VIDC soundcards. I'd guess there's a bit more work to it than just replacing all the "Sound_" SWIs though.

But to be so vague as to not know what the features you want are, and not even bother thinking about it... well.
You say animating sprites is a major job, and so it can be. But so is programming. And so is designing a suitable and user-friendly interface. Any even slightly experienced programmer will tell you that you should have a good plan before you start the code. For you to treat this so casually suggests to me that you don't appreciate the effort involved.

*grins* While I see what's amusing I should point out that Andrew is well aware of the efforts involved. He wrote Overcast and was making progress with Overcast II. I think other commitments have caused that project to stall.

I know I don't help because I'm always telling him there are better tools on other platforms. Unfortunately I tend to mean 3D tools. I've heard that Deluxe Paint on the Amiga was supposed to have some kind of help for sprite animation but I can't track down exactly what it was and I don't know anyone who has used it, or has an Amiga with a copy.

<blockquote>&lt;font color=&quot;#667799">I'd need to see what kind offeatures are available in some of the packages I've been told about. It's hard to see that they wouldn't make life a huge lot easier than the current situation.

It's a major, major job animating game sprites if you want them to look half-decent.&lt;/blockquote&gt;&lt;/font&gt;

To be honest I find this response amusing.
Perhaps if you were to nail down exactly what it was you wanted - or preferably discussed it in great detail in an appropriate forum (like the graphics section of the icon bar) - you might have a chance of persuading a programmer to make it for you.

But to be so vague as to not know what the features you want are, and not even bother thinking about it... well.
You say animating sprites is a major job, and so it can be. But so is programming. And so is designing a suitable and user-friendly interface. Any even slightly experienced programmer will tell you that you should have a good plan before you start the code. For you to treat this so casually suggests to me that you don't appreciate the effort involved.

What's this ? You're determined to take a swipe at me personally it seems which is spillover from discussions on TIB where you objected to the fact that I was expressing reasoned and valid opinions. I'm saying what is needed here, which is more than nothing which we have at the moment.
I've said I talked about packages available on other platforms to somebody who works in the field and I'd need to review what their features were again before persuading or suggesting ideas to anybody.
If you know of any features that might be helpful then feel free to suggest but stop picking at me as it tends to suggest a personal dislike which doesn't really have a place here.

[Edited by andreww at 14:45, 29/1/2003]

<blockquote><font color="#667799">But to be so vague as to not know what the features you want are, and not even bother thinking about it... well.
You say animating sprites is a major job, and so it can be. But so is programming. And so is designing a suitable and user-friendly interface. Any even slightly experienced programmer will tell you that you should have a good plan before you start the code. For you to treat this so casually suggests to me that you don't appreciate the effort involved.</blockquote></font>

*grins* While I see what's amusing I should point out that Andrew is well aware of the efforts involved. He wrote Overcast and was making progress with Overcast II. I think other commitments have caused that project to stall.

I know I don't help because I'm always telling him there are better tools on other platforms. Unfortunately I tend to mean 3D tools. I've heard that Deluxe Paint on the Amiga was supposed to have some kind of help for sprite animation but I can't track down exactly what it was and I don't know anyone who has used it, or has an Amiga with a copy.

Yes I have other commitments now and they may well have stalled the project Lee you're right but at the time animating the 3D sprites was becoming inhibitive and an excessive burden on my free time than should a hobby I think. I was hoping to stimulate some ideas from people in the know here as, like I said, it has been brought to my attention that decent packages were available for the Amiga.

What's this ? You're determined to take a swipe at me personally it seems which is spillover from discussions on TIB where you objected to the fact that I was expressing reasoned and valid opinions.

I'm saying what is needed here, which is more than nothing which we have at the moment.

but that was my point - you wern't. If I can sum up:

Andrew: we need better animation tools.
Tony: Like what? (Like this? gives example)
Andrew:I don't know.
Tony: How do you expect people to produce the tools you want when you don't know yourself?
Andrew:Stop being personal!

I've said I talked about packages available on other platforms to somebody who works in the field and I'd need to review what their features were again before persuading or suggesting ideas to anybody.
If you know of any features that might be helpful then feel free to suggest but stop picking at me as it tends to suggest a personal dislike which doesn't really have a place here.

If you read up the thread a way you'll see I made a couple of suggestions. I was hoping we could have a discussion about what was required, bounce ideas off each other, work on the interface concepts, invent new ideas and take the best off other platforms. While I didn't give a false promise of writing something I did say it wouldn't be too hard to write something with the basic features in place which would probably suit your needs. Instead you were dismissive.

So... Why don't you delete all the stuff above here in your response and get back to the subject.

I was initially thinking of a sort of row of sprites in a single window, so you'd use the horizontal scroll bar to get from one to the next.
I now think this might be sub-optimal. It would be preferrable to be able to work on an arbritrary position of the sprite in a window, then jump to the same position in the previous/next sprite. So you could have previous/next sprite buttons in a pane attached to the window.

The big problem is that you want to be able to see the state of the previous/next sprite(s) ideally in the same place as the actual editable pixels. There are several possibilities:
*The image could flicker between the 2 (or 3) sprites.
*The next/previous sprite could be displayed interleaved with the current one, perhaps as a small box say at the bottom right of each enlarged pixel.
*There could be seperate images alongside the editable one, all showing the same subset of the sprite, but with different sprites.
*Possibly others I haven't thought of.

You can see that I am assuming that an animation is a linear series of sprites each with the same dimensions - but is this generally true? Would it do for the animation editor, with post-processing possible in Paint?

Would it be best to have a different filetype for animations? - you'd need to be able to convert things to and from spritefiles as easily as possible.

This is the sort of thing I want to see you talk about.

At no point have I dismissed your ideas. You're living under some kind of delusion there Tony.

I only complain about misrepresentation when necessary which is quite often unfortunately where youre concerned.

Well I don't buy that response for a second! I've explained what kind of things I'd like to see

<snip>

And what on earth are you prattling on about with the 'ignoring my programming ideas' thread!!?

Well to copy and paste part of a message from here

AW: I think so but could be the problem. I get 2 sprites plotted of half the height and with the rest filled with junk!??

[TH]
Sounds to me like 2 problems...
What screenwidth are you using? Appearing to have two half-height sprites is fairly common to me. It means you've only added on half the screen-width. If you examine the two half-height sprites you should find that they are slightly different, being the odd and even sprite row datas. If your screen width is 1280 pixels it will be double that in bytes, in 32thou. colours.

[followed by comment that you should check your sprite height counter]

You then start a new thread where you say:

I'm plotting a 32K sprite using a routine I've used before but I'm getting a double image effect (the sprite is appearing twice: once where it should be on the rhs and once in the middle of the x-axis of the screen)<snip>...

Jeffrey responds with

The most obvious problem would be adding on 1 times the screen width instead of 2 times at the end of each row... <snip>

Which you then say has solved the problem.

...
Does that qualify?

<snip>

Regarding the sprite animation program I said I'd have to look at what features were available but that I would find it hard to believe they wouldn't make life easier than the current situation is for making half decent animations. I'm not saying it's impossible just difficult. The fact that packages exist and have been used to produce high quality graphical games suggests to me that there is a need for software more than Paint. I might look into it more but what I was interested in was hearing the views of others and your argument was along the lines of 'Paint is ok for me' which is perfectly valid for you to say obviously. I then tried to get across it wasn't enough in my experience which provoked strangely what seemed to me an unreasonable backlash at me personally.<br><br>[Edited by andreww at 14:43, 30/1/2003]

[Edited by andreww at 14:44, 30/1/2003]