News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_AMSDOS

My Absurd Demos from the 90s

Started by AMSDOS, 06:14, 27 October 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AMSDOS

Back in the 90s I was putting together game discs and writing my own little Menus to select the game, though along with that Menu I also had a little demo. Sometime ago I transferred some of those from disc to disk image and came across a couple a few weeks ago and decided to update them :D



They aren't going to set the world on fire in terms of tricks there's no Rasters or Overscan or Split Modes, I did make one little Demo back then which used a program from AA17 Type-ins to split the Colours midway across the screen, though haven't included it here.





Police Car Demo

The original program is called CAR.BAS, which is a BASIC stub file (a file with BASIC followed by MC routines), back when I made it, I was using the Spriting Back Utility which was on the AA106 Covertape, which had it's own Sprite Designer. The idea with it was to draw a rectangle around the sprite and set it to 0 or whatever the background colour was, so it would wipe the Sprite as it moved. Apart from that the routine has it's own guide to how to set coordinates across the screen, I must of known how it work back then because it's quite different to Sean McManus' ESD Advance for example. The other feature of this demo is the Screen I made back then, I probably made it with the early GPaint from the AA80 covertape and then I used the early version of Colombia to compress the screen, which is what you can see in operation onscreen when CAR.BAS is initially RUNning.





Updated BASIC Version

It's still using the Spriting Back Utility from the AA Covertape, though I decided to use BASIC to draw the screen, the hardest part is the nature strip, I had to come up with a simple way of checking both sides of the curve and use MOVE and DRAW to fill those two points in, thus creating a simple FILL routine, I wasn't sure how good it would be, so I straightened out the angled edges, which left me with a bit of line to draw at the end, though generally speaking the general idea is there even if the median strip is slightly different. For the red dots to be placed in the centre of the Grassy area, it was simply a matter of working out Random Values between the 2 Points again, though use some conditioning when the Median Strip changed so it would remain within. Overall, I was happy with the result. The resulting program is called PATROL.BAS


Coding in Hisoft Pascal

From the BASIC version, I was able to come up with a Pascal equivalent, though I've been using Sean McManus' Easi-Sprite Driver Advanced, so I had to convert the sprite so it had dimensions and also changed the sprite to XOR, which means a Border isn't necessary. Since it's only a single Sprite, I also used Hisoft Pascal to build the Graphic up in sets, so the whole program handles everything from within. The most noticeable change between this and the BASIC version is obviously going to be the FILL routine, from the compiled environment it looks similar to the BASIC 1.1 FILL. The resulting Compiled Program being in PATROL.BIN


Police Cars aren't White!

Well maybe not now, but back in the 90s they were, well I suppose some still are here in Australia, a Highway Patrol car perhaps isn't, this looks more like your little Suburban Car doing it's rounds!  :D 







The Cliff Man!

I never really had a title for this, it's simply a little Viking Character I drew up myself charging from one side of the screen to the other, with a Cliff in it's Path. Back when I wrote it I had no concept of Array's so no check routine to check when he should drop, I haven't complicated things by adding one either and have just stuck to the old true method of Drawing this character so far before having them drop, this demo really shows how well my Animation sequencing works and even now it's a simple 2 sprite approach. Like my 1st Demo, this also used the Spriting Back Utility and with again Invisible Box placed around.




I updated again using ESD Advanced with Hisoft Pascal just to see how well the Animation with a Background in play would perform, was also an opportunity to use the simple mask pattern generator to draw a background, however while I was in the process of using it, I found a bug which relates to when the position changes (from the left side of the screen it works perfectly fine, but offsetting the x-coordinate and problems begin to emerge, the solution which I hadn't done in my BASIC example was to add X to the Final value from within the FOR loop, thus correcting that), in this demo the pattern shifts when the 1st lot of ground on the left side is found and needs to follow down to the displaced ground that the Viking Falls down to. Overall again I'm happy with the result.  :D




* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

AMSDOS

Had a bit of a read up on the Spriting Back Utility from the AA106 Covertape Page, it appears Simon Forrester was going to write a followup article about it, though it appears it never eventuated. It's been setup though for someone new to Sprites and looking to add Sprites into a simple program. The Coordinate system is setup to be quite broad though, it's not a true Text Coordinate system, although in a sense it's setup as a grid 80 squares across (equivalent to MODE 2), 50 squares down, which would make that every 8 pixel lines, which when running in conjunction with my earlier Demos is the reason why the Sprites Move quickly across the screen.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Gryzor


AMSDOS

Something's been bugging me about my Cliff Man! Demo unfortunately which I compiled using Hisoft Pascal, CLIFFMAN.BIN
This demo was posted on CPC-Power, but in one of the screenshots bits of my Character were missing, so I played around with CTRC settings in Winape and CPCBox and found different CTRCs settings were having an impact of the result as well as my Sound Routine. Everything seems to work as it should when Type 0 CTRC is used, but Type 1 & 2 seem to be running the demo faster as well as showing the top portion of my Sprite while it's on the Top Platform, when in Freefall, the Sound commences but doesn't cease when the Sprite reaches the Bottom Platform (that's what occurred while I was playing around with it in Wiinape). Ok, perhaps I shouldn't be poking around with CTRC settings and I should only have it on 0 for emulating 464, though I'm mighty confused since I've setup Winape to emulate a 464, I'm unsure what I'm meant to have for it (CTRC wise), though I got the impression it depends on when that 464 was built, which leaves me concerned that my demo may look good on some real computers, but crap on others. I'm also confused because after reading the CTRC guide, it details stuff which I'm not even using, so like why for example is sound performing correctly for one CTRC, but wrong on others when all I've made is a simple Firmware Sound Queue which waits until the no carry (nc) is true?
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

mr_lou

Not sure how I missed this thread first time around.

Looks very nice! Great material for an 8-bit Memoirs story.  ;)

andycadley


CRTC differences seem unlikely to make any noticeable difference in anything like this, it's almost always when you're pushing the limits when it actually matters. It's possible if you're trying to read various CRTC registers that you'll get different results, but again that seems unlikely as there would be little reason to do so.

AMSDOS



Quote from: mr_lou on 14:22, 08 December 18
Not sure how I missed this thread first time around.


Looks very nice! Great material for an 8-bit Memoirs story.


Sadly I don't advertise my materials very well and after presenting these Demos I move onto something else to code.
What got me concerned was after I noticed a Screenshot on CPC-Power of "The Cliff Man!" demo with bits of the Main Character missing (mainly the bottom half). I played around with it on CPCBox as well as Winape and the output looks great when CRTC 0 is using it, but terrible is it's anything else.

Quote from: andycadley on 14:27, 08 December 18CRTC differences seem unlikely to make any noticeable difference in anything like this, it's almost always when you're pushing the limits when it actually matters. It's possible if you're trying to read various CRTC registers that you'll get different results, but again that seems unlikely as there would be little reason to do so.



I would generally agree, unfortunately I transferred the demo to my 6128 and the results from that weren't good. I made a as poor in quality as it is, the character is invisible along the top in the 1st few frames until it reaches that falling position, at the 18 second mark the character is visible along the top platform which is blinking. At one point after exiting the demo with ESC and running at the RUN (y/n) prompt again, the character was doing something like the emulators were doing after altering to CTRC 1 & 2, printing the top portion of my character with gradual flashes of it's body and legs. The sound is also out, which is meant to cease when my character reaches the bottom ground, the Video from my 6128 also confirms this isn't the case :(  I tested this out earlier to see if it was a Firmware 1.0/1.1 thing occurring, but found that using an emulated 6128 with CTRC 0 was no different to emulated 464. Sadly I don't know what CTRC my 6128 is using guessing it using either 1 or 2, on one occasion while using CPCBox with CTRC 2 after exiting and running a couple of times the program was performing correctly.
So I can only guess that if there's nothing in my code which should affect it, then perhaps Hisoft Pascal is doing something during initialisation phase?
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

andycadley


The character being invisible near the top of the screen is almost certainly a result of the background graphics being restored before the "sprite" is being drawn. The raster beam is updating the display before the code gets around to printing the sprite, so it just draws what is in the video memory at that time which happens to be the background pattern.


You can see this happening in WinAPE if you slow emulation right down to like 10% speed, on some frames the sprite isn't entirely there at the point the screen is drawn (this is where the flicker comes from you can see at normal speed). Additional ROMs or Firmware /BASIC revisions may well also magnify this effect to some degree because they're potentially running more code as part of the frame flyback interrupt than a stock 464. FWIW switch CRTC in WinAPE doesn't really seem to make any noticeable difference to me regardless of which CPC I have WinAPE set up as (and I wouldn't expect it to).


The sound issue is stranger, but it's possible Hisoft Pascal does something odd somewhere along the way that doesn't work all the time or that gets upset by some other combination of ROM/firmware in an unexpected way.

AMSDOS


I've played around with the code, so this was what I originally had for moving the Graphics:



1910 PROCEDURE movacross(startpos,endpos,yaxis : integer);
1920 BEGIN
1930   WHILE startpos<=endpos DO
1940   BEGIN
1950     grab(#A0A0,startpos,yaxis,6,12);
1960     overlay(#A000,startpos,yaxis);
1970     user(#bd19); user(#bd19); user(#bd19); user(#bd19);
1980     force(#A0A0,startpos,yaxis);
1990     startpos:=startpos+2
2000   END
2010 END;
2020
2030 PROCEDURE demo;
2040 VAR xpos : integer;
2050     ypos : integer;
2060 BEGIN
2070   xpos:=0; ypos:=187;
2080   movacross(0,78,187);
2090   xpos:=78; ypos:=ypos-1;
2100   ent(-6,3,1,1);
2110   snd(1,200,260,12,0,6,0);
2120   WHILE ypos>=123 DO
2130   BEGIN
2140     grab(#A0A0,xpos,ypos,6,12);
2150     overlay(#A04A,xpos,ypos);
2160     user(#bd19); user(#bd19); user(#bd19); user(#bd19);
2170     force(#A0A0,xpos,ypos);
2180     ypos:=ypos-2
2190   END;
2200   ypos:=ypos+1;
2210   movacross(xpos,148,ypos)
2220 END;



with the 'movacross' procedure moving the character across the screen to this:



1910 PROCEDURE movacross(startpos,endpos,yaxis : integer);
1911 VAR osp : integer;
1920 BEGIN
1921   IF startpos=2 THEN force(#A0A0,0,187);
1930   WHILE startpos<=endpos DO
1940   BEGIN
1950     overlay(#A000,startpos,yaxis); user(#bd19); user(#bd19);
1960     osp:=startpos; startpos:=startpos+2;
1970     force(#A0F0,osp,yaxis);
1980     grab(#A0F0,startpos,yaxis,6,12)
2000   END;
2001   force(#A0F0,startpos,yaxis);
2010 END;
2020
2030 PROCEDURE demo;
2040 VAR xpos : integer;
2050     ypos : integer;
2055     d    : integer;
2060 BEGIN
2070   xpos:=0; ypos:=187;
2071   grab(#A0A0,0,187,6,12);
2072   grab(#A0F0,2,187,6,12);
2073   overlay(#A000,0,187); user(#bd19); user(#bd19);
2080   movacross(2,78,187);
2090   xpos:=78; ypos:=ypos-1;
2100   d:=400;
2120   WHILE ypos>=123 DO
2130   BEGIN
2131     snd(1,d,2,15,0,0,0);
2132     d:=d+10;
2140     grab(#A0A0,xpos,ypos,6,12);
2150     overlay(#A04A,xpos,ypos);
2160     user(#bd19); user(#bd19);
2170     force(#A0A0,xpos,ypos);
2180     ypos:=ypos-2
2190   END;
2191   grab(#A0F0,xpos,ypos,6,12);
2200   ypos:=ypos+1;
2210   movacross(xpos,148,ypos)
2220 END;



So the 'Demo' procedure runs the entire demo. I removed the ent, snd commands in the initial demo after discovering that entering that in BASIC the Sound Carries on longer than it should, Hisoft Pascal seems to have a way of clipping the sound, though in other scenarios the sound was being correctly played which was in the same manner as the BASIC.
The updated 'demo' procedure now uses grab to capture two parts of the screen with overlay to draw my main character onscreen before 2 MC FRAME WAIT. The 'movacross' procedure places my main character at the next position, though if startpos is at the beginning, I use force to draw the background in before entering the loop and drawing the next position using overlay. An old start position (osp) is obtained with 'startpos' being incremented. background is drawn back (using force) at the 'osp', a new background is captured before returning to draw the man using overlay. When the Loop has reached the end position, background is drawn back.


Everything looks good now, even on my 6128, apart from the part which is drawing my Man in Free-fall, this is now flickering away! :o But returns to normal when drawing the man moving along the lower platform. I tried tinkering with this, but ended up with graphics being half drawn again  So have reverted back to this because this seems to be about as good as I can get it.


The routines I'm using come from Sean McManus' Easi-Sprite Driver Advance (or ESD2) and in his demo programme, Sean has placed a CALL &BD19 after the overlay routine, though there seems to be different ways in where a FRAME or CALL &BD19 should be placed. The Cover story "Get Things Moving" from AA101 has a box about this where it explains how it should be used before drawing the Graphics to reset the scanline to the top of the screen, though I can see from my example my flicker relates to when the graphics are drawn and at what state, does this mean I should be using FRAME after forcing background graphics onscreen?


I've updated programme in a new DSK image (see below), the new file is called CLIFFMAN2.BIN
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

andycadley


The "right" place is a somewhat nebulous concept, as it really depends on how your drawing code works exactly. A call to &BD19 means the system will hold off till the frame flyback, so at that point in time the raster beam will be right at the start of the frame - it generally moves faster than you can draw, so you need to think about where it will be when you do so.


A good starting technique, if you don't have much to draw, is to wait for frame flyback, delay slightly and then draw items on screen from the top to the bottom - hopefully just after that bit of screen has been displayed - this is described as "chasing the raster" because you're attempting to update the screen just after it has been read. You can hone this technique somewhat by keeping track of interrupts that occur because they will give further indication of when the raster beam has passed certain sections of the screen.


Another common trick is to draw the display line by line starting at the bottom and moving upwards - the idea being that you are less likely to have the raster scan interfere with what you are doing. Sprite drawing routines that handle masking/erasing into offscreen buffers can also help, as they reduce the possibility that something will flicker, reducing it to a tearing effect at worst.


A good technique for figuring out where the raster is when your code runs (as well as how long it takes) is to temporarily change the border colour before starting a routine and then change it back afterwards, as this will visually indicate the part of the display being refreshed during that segment of code. Don't trying using the firmware routines for that though, since they synchronise palette changes with the start of a frame, IIRC.

Powered by SMFPacks Menu Editor Mod