Sugarlumps Demo|sourcepack)Coding Sources
 ★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

A bit of a long answer, but never mind... 

The raw copy/fill routine works out to be 5 cycles per pixel, so 5*64*48=15360 plus some overhead, which is less than a frame. In reality, though, extra cycles are needed for the chunky mode effect and also for the interrupt handling. However, one thing to remember is that the time spent in the portion of the screen in the chunky display needs to be accurately cycle counted to get the effect to work correctly. Given that the the copy/fill routine can be exactly cycle controlled, I decided to do the copy/fill processing only during the chunky area of the screen. So, the copy/fill code takes about 1.4 frames to render. However, this also means that 1/3 of each frame isn't used and so can be used to calculate the next frame.

That still leaves at about 0.6 periods of chunky areas unused per 2 frames, so I decided to use that to do my triangle filling. I optimised the inner loop of the Bresenham line algorithm and got it down to a constant 20 cycles per step - so again, this is ideal for fitting around an accurate cycle counted chunky area. So, I end up with 3 possible code paths for the chunky area of the screen:

  • Drawing lines into the copy/fill buffer for the whole area
  • Drawing lines into the copy/fill buffer for the top half, copy/filling the top 1/3 of the screen
  • Copy/filling the bottom 2/3 of the screen
  • The last 2 steps work fine because the beam has already rendered past the area of screen being updated at any point, so no tearing is visible.

Also, the fastest a complete this code will run at is in 2 frames (as happens with the twister) but could take much longer if there is triangle filling work to do. Interestingly, the twister subverts the code path slightly because this demo was always meant to be a triangle drawing demo not a twister demo! Most of the demo updates the screen every 3 frames.

So, back to that spare 1/3 of the CPU time - of the 312 screen lines, between 192 and 200 are used to handle the filling process, leaving about 100 or so free after the music interrupt and scroller. During this time, we're generating data for the Bresenham inner loop. To avoid the possibility of rendering data before all sides of the triangle are drawn, I actually triple buffer these buffers!

I've actually already tidied up the source ready for release, but I'll hold off releasing it until after the next demo as the process described above will be largely untouched in the next demo - that'll be all about the 3D code to generate the required triangles...


★ YEAR: 2012


Other platform tools:
» sugarlumps  sourcesDATE: 2012-11-12
DL: 70 fois
SIZE: 54Ko

» sugarlumps  sources    (Added  ROM  version)DATE: 2014-05-06
DL: 22 fois
SIZE: 55Ko

Je participe au site:
» Newfile(s) upload/Envoye de fichier(s)
★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

» Coding Src's » Graphic - Curtains (Amstrad Computer User)
» Coding Src's » Graphic - Christmas Card (Popular Computing Weekly)
» Coding Src's » Execution d'une instruction BASIC en assembleur
» Coding Src's » Graphic - Vax Silly's Snowflake (Amstrad Computer User)
» Coding Src's » Zellautomat (CPC Amstrad International)
» Coding Src's » Prevents two linefeeds

CPCrulez[Content Management System] v8.75-desktop/cache
Page créée en 278 millisecondes et consultée 1107 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.