At 09:22 �� 16/2/2002 +0000, you wrote: >Phoebus R. Dokos wrote: > >>Well I had this program for ages and I never even tried it!!!! >>Nasta is right, it doesn't run with anything other than the original QL >>screen addresses which makes me wonder if QPC2_v3 could run it right. >>(Screen at $20000) >>It doesn't appear to mess up anything else and I suspect that animations >>run in the memory space of the original screen. The thing is that QPC >>doesn't hang! >>(Also it needs TurboTK instead of the extend_code as most other DP apps >>which leads me to believe it was originally written in Turbo Compiled >>S*Basic....) > > >xtra_code contains SUPERCHARGE extensions (SET_PRIORITY, REMOVE_TASK, >LIST_TASKS, END_CMD, DEVICE_STATUS, FREE_MEMORY) which are (presumeably) >used by the Supercharged DESIGN and CONSTRUCT.
Which is subset of Turbo IIRC so works either way :-) >> so the question is now : Who wrote it? > > >Looking at sprite_code (off DP disk 9!) it contains "R.Woodhouse 1986" >right at the end. Oh I see... >> If I could get my >> hands on the original code .... :-) > > >I think you'll find that all the code is prob assembler within sprite_code >to add the extra procs: SPRITE, SSGON, SSGINIT, SSGSWAP, SSGFILE, SSGMODE, >and FNs: SSGEDGE, SSGHIT, SSGEDGE%, SSGHIT%. > >Given an hour or 8.358 I'm sure I could generate a (tidyish) source for >sprite_code (wonderful inventions disassemblers - try IDIS, also on DP disk 9). I was trying to avoid that... >>It is amazing though, very smooth animation and exactly what I want to >>do, you can even switch apps and the sprites keep on going.... (Just the >>way I want :-) >>Could it be written by SNG? > > >R.Woodhouse mefinx...funny, I was at school with a R.Woodhouse; wonder if >it was same bloke. > > >>Phoebus > >Try also a look at the manual (also on DP disk 9) SSG_DOC. Yes I checked it out but only mentions the procedures nothing regarding where its written at etc.. >Or am I just tired from the drive back to Llundain from Glasgow (flat out >at 62.5 mph) and have totally misread the problem? Not totally, I am just trying to avoid to reinvent the wheel... but I am afraid I'll have to... at least with a Thing solution I'll be able to use pipes as well to supply the sprite animator with the paths of the sprites... :-) And best of all it would be reusable... :-) Phoebus
