Fastest way to load a file

[baggey]

could this be done with the actual screen buffer were i could write the 8 bits? But then i suppose it would need to be coloured as well?

   Not following you.

What i think i mean is.

At the moment im working on the simulate loading of the speccy screen buffer!
i ve tried a few ways but im getting horrible flashing etc? I trying to do it realtime our i probably need to make it appear realtime.

The idea:

     Jump ito the function screen_simulate()
   
     RENDER TO SCREEN clear it and sync etc to get a blank screen.

     I now have the 16384 start and 22527 end address of the screen buffer.
     I pull the displaybyte, the address 16384=0 for y and 16384=0 for x coords.
     stored in image_cache2 is the already loaded image of what we want to simulate but its in colour! May be a pointer coul just get the bytes an not the colour of the pixels?
     Or glscrfile() array which holds both, but maybe pointers arn't needed as will be delaying anyway?

    Now. Using the array scr_lines(lne,0.....31) and 32 for something in this row needs displaying. We make it true just to paint this byte!
    I now have fastdot 0 , 0....7 bits to display but in black and white as its a loader image! In the paintscreen() routine i have the black and whit colours (; out).
    So a quick check to see wether were in simulate or not to pull colour or black and white.

    So.
    Now we need to plot these bits at 0,0 and display them!
    Show screen and then plot next address, then show them etc. But with a delay, as it was visually something too see. Just like flash timer routine!

    Im thinking i have display bytes in glscrfile(). Which includes 6144 of display bytes and 768 of attribute bytes. scr_lines(y,x) as above.
    As im doing it with a delay, i probably don't need the speed of a bank.

    If you have any ideas for this type of approach, im intrigued.

    Writing to an image and copying to  the screen by flipping is easy. But by doing byte by byte, im missing the point!?

    I will get there! but being sent up the write path to start with. Will save me a lot of time and effort, as did my menu for (scr, selection menu with pictures)!

Kind regards Baggey

[baggey]

Latest version of simulate screen function. But painting 32 colums with last byte called?

PlayBASIC Code: [Select]

psub simulate_scr() ;// This could end up being morealess the same routine for altering a display byte when emulating the Z80! 

getscrfile()
;simulatescrmode=true
rendertoimage img_cache1
SeedbufferRead=Point(0,0)
lockbuffer
cls
unlockbuffer

rendertoscreen
SeedbufferRead=Point(0,0)
lockbuffer
cls
;unlockbuffer

;rendertoscreen

;lockbuffer
 ;SeedbufferRead=Point(0,0)
   
     for scrnaddr=16384 to 16388; Just top 4 bytes for now! Just to see it working!?
      
      // Gets the display byte to display   
       displaybyte=glscrfile(scrnaddr-16384)
       // Gets the display byte y coord   
       displayy=glscreenaddry(scrnaddr-16384,1)
       // Gets the display byte x coord
       displayx=glscreenaddrx(scrnaddr-16384,1)   
                ;glscreenmem(y,x)   
               print ""
               print ""
               print "display address = "+str$(scrnaddr)
               print "displaybyte = "+str$(displaybyte)
               print "display y pos = "+str$(displayy)
               print "display x pos = "+str$(displayx)
               
      // if y,x byte needs painting. make it true
      // just force the line and byte to be painted!!
      ;forcerepaint()
      ;scrnlines(191,32)=true
      scrnlines(displayy,32)=true
      ;scrnlines(191,248/8)=true
      for i=0 to 31
         scrnlines(displayy,i) = false
         next i
               scrnlines(displayy,displayx/8) = True
      scrnneedrepaint = True
      print "Going into paint function"
      print "   screen line "+str$(displayy)+","+str$(displayx/8)+" = "+str$(scrnlines(displayy,displayx/8))
      print "   screen line "+str$(displayy)+","+str$(32)+" = "+str$(scrnlines(displayy,32))
      // The idea here is we have displaybyte BYTE, x,y coords, scrnlines altered so only these can be painted!
      // scrnneedrepaint just makes sure the paint routine is run.
            paintscreen(1) ;Frezzes when i go here?
      
            fastdot 50,50,rgb(200,200,200)
            
      // Still painting 32 colums hmm!?
            rendertoscreen
            print "coming back from paint function"
            print "   screen line "+str$(displayy)+","+str$(displayx/8)+" = "+str$(scrnlines(displayy,displayx/8)); not changed to false??
            print "   screen line "+str$(displayy)+","+str$(32)+" = "+str$(scrnlines(displayy,32))
            
            SeedbufferRead=Point(0,0)
            lockbuffer
            Scalex#=float(float(GetSurfaceWidth()-120))/float(getimageWidth(img_cache1))
            Scaley#=float(float(GetSurfaceHeight()-60))/float(getimageHeight(img_cache1))
            drawrotatedimage img_cache1,59,28,angle#,scalex#,scaley#,0,0,true 
            unlockbuffer
            ;waitkey
            
            ;sync      
   next scrnaddr
;unlockbuffer
  sync
   waitkey
   simulatescr=false
   simulatescrmode=false
endpsub

[baggey]

AH!!

just realised that the paint function needs this alteration of code!

PlayBASIC Code: [Select]

If scrnlines(lne, (X/8)) = True
// displaybyte is what the byte to be plotted is
    on displaybyte gosub DB_0,DB_1,DB_2,DB_3,DB_4,DB_5,DB_6,DB_7,DB_8,DB_9,DB_10,DB_11,DB_12,DB_13,DB_14,DB_15,DB_16,DB_17,DB_18,DB_19,DB_20,DB_21,DB_22,DB_23,DB_24,DB_25,DB_26,DB_27,DB_28,DB_29,DB_30,DB_31,DB_32,DB_33,DB_34,DB_35,DB_36,DB_37,DB_38,DB_39,DB_40,DB_41,DB_42,DB_43,DB_44,DB_45,DB_46,DB_47,DB_48,DB_49,DB_50,DB_51,DB_52,DB_53,DB_54,DB_55,DB_56,DB_57,DB_58,DB_59,DB_60,DB_61,DB_62,DB_63,DB_64,DB_65,DB_66,DB_67,DB_68,DB_69,DB_70,DB_71,DB_72,DB_73,DB_74,DB_75,DB_76,DB_77,DB_78,DB_79,DB_80,DB_81,DB_82,DB_83,DB_84,DB_85,DB_86,DB_87,DB_88,DB_89,DB_90,DB_91,DB_92,DB_93,DB_94,DB_95,DB_96,DB_97,DB_98,DB_99,DB_100,DB_101,DB_102,DB_103,DB_104,DB_105,DB_106,DB_107,DB_108,DB_109,DB_110,DB_111,DB_112,DB_113,DB_114,DB_115,DB_116,DB_117,DB_118,DB_119,DB_120,DB_121,DB_122,DB_123,DB_124,DB_125,DB_126,DB_127,DB_128,DB_129,DB_130,DB_131,DB_132,DB_133,DB_134,DB_135,DB_136,DB_137,DB_138,DB_139,DB_140,DB_141,DB_142,DB_143,DB_144,DB_145,DB_146,DB_147,DB_148,DB_149,DB_150,DB_151,DB_152,DB_153,DB_154,DB_155,DB_156,DB_157,DB_158,DB_159,DB_160,DB_161,DB_162,DB_163,DB_164,DB_165,DB_166,DB_167,DB_168,DB_169,DB_170,DB_171,DB_172,DB_173,DB_174,DB_175,DB_176,DB_177,DB_178,DB_179,DB_180,DB_181,DB_182,DB_183,DB_184,DB_185,DB_186,DB_187,DB_188,DB_189,DB_190,DB_191,DB_192,DB_193,DB_194,DB_195,DB_196,DB_197,DB_198,DB_199,DB_200,DB_201,DB_202,DB_203,DB_204,DB_205,DB_206,DB_207,DB_208,DB_209,DB_210,DB_211,DB_212,DB_213,DB_214,DB_215,DB_216,DB_217,DB_218,DB_219,DB_220,DB_221,DB_222,DB_223,DB_224,DB_225,DB_226,DB_227,DB_228,DB_229,DB_230,DB_231,DB_232,DB_233,DB_234,DB_235,DB_236,DB_237,DB_238,DB_239,DB_240,DB_241,DB_242,DB_243,DB_244,DB_245,DB_246,DB_247,DB_248,DB_249,DB_250,DB_251,DB_252,DB_253,DB_254,DB_255
endif      

[baggey]

Again chipping AWAY! ive an endif statement in the wrong place. Within the paintscreen() function. But works a treat until the screen load emulation!?

PlayBASIC Code: [Select]

         next x
         
      // At line 0....191   32   Is paint something in this line no longer
        scrnlines(lne, 32) = False
         endif
      next lne

who would of thought that?

its fun learning!

baggey

[kevin]

At the moment im working on the simulate loading of the speccy screen buffer!

   While I'm really not understanding why you need to specifically program a routine to simulate loading,  as the emulation will do this anyway.  I'd just load the 'chunk of data'  into memory, render the page then copy it on in chunks..



  While skimming though your code a couple of points that come to mind,

  Bellow we've classic example of operational redundancy.  Three expressions that all share a common calculation, so you can rid of two of operations by caching the calc and using the cached result as the array index.  

 so this,  

PlayBASIC Code: [Select]

      // Gets the display byte to display   
       displaybyte=glscrfile(scrnaddr-16384)

       // Gets the display byte y coord   
       displayy=glscreenaddry(scrnaddr-16384,1)

       // Gets the display byte x coord
       displayx=glscreenaddrx(scrnaddr-16384,1)   

    should be,

PlayBASIC Code: [Select]

        RealScreenAddress=scrnaddr-16384

      // Gets the display byte to display   
       displaybyte=glscrfile(RealScreenAddress)

       // Gets the display byte y coord   
       displayy=glscreenaddry(RealScreenAddress,1)

       // Gets the display byte x coord
       displayx=glscreenaddrx(RealScreenAddress,1)   

   




  CopyImage is a destructive process, meaning the destination surface is being deleted and then re-allocated, then having the pixel data copied across.    There's a number of way to do that same thing without the de-allocation and allocation overhead, such as drawing one image onto the other, or using CopyRect.   The later is probably better, but requires the sizes.  

PlayBASIC Code: [Select]

   global img_cache1 = newfximage(257,193)
   global img_cache2 = newfximage(257,193)


   Max=100

   Do
         cls 
         
         frames++

         t=timer()         
         For lp =0 to max
               CopyIMage img_cache1,img_cache2 
         next
         tt1#+=timer()-t
         print tt1#/frames         


         t=timer()         
         For lp =0 to max               
               FasterCopyIMage(Img_Cache1,img_Cache2)
         next
         rendertoscreen
         tt2#+=timer()-t
         print tt2#/frames         


      Sync
loop


Psub FasterCopyIMage(Src,DEst)
   old=getsurface()
   rendertoimage dest
   drawimage Src,0,0,false
   rendertoimage old
EndPsub

      There's a number of fragments in the program that have unnecessary locks and over casting.     The float of a float or float casting in the expression simply isn't needed, if you want floating point result from any Math operation, then only one term needs to be a float on either side of the operator.  The casting  will automatically   cast a division between an integer and float as floating point divide.  

PlayBASIC Code: [Select]

   print 10/3         ; int divided by int
   print 10/3.0      ; int divided by float
   print 10.0/3      ; float divided by float 
   print 10.0/3.0      ; float divided by float 
   
   sync
   waitkey

   See Variable Casting and Math operations


   So this,

PlayBASIC Code: [Select]

         SeedbufferRead=Point(0,0)
            lockbuffer
            Scalex#=float(float(GetSurfaceWidth()-120))/float(getimageWidth(img_cache1))
            Scaley#=float(float(GetSurfaceHeight()-60))/float(getimageHeight(img_cache1))
            drawrotatedimage img_cache1,59,28,angle#,scalex#,scaley#,0,0,true 
            unlockbuffer
         

    Really should be this,

PlayBASIC Code: [Select]

            lockbuffer
            Scalex#=(GetSurfaceWidth()-120)/float(getimageWidth(img_cache1))
            Scaley#=(GetSurfaceHeight()-60)/float(getimageHeight(img_cache1))
            drawrotatedimage img_cache1,59,28,angle#,scalex#,scaley#,0,0,true 
            unlockbuffer
         

   
    Since they're bracketed you cna get rid of the float casts by making the literals floats.   The subtraction between and INt and float will produce a float result, which is then divided by an integer.  

    So it could be this to strip a few more operations out

PlayBASIC Code: [Select]

            lockbuffer
            Scalex#=(GetSurfaceWidth()-120.0 )/getimageWidth(img_cache1)
            Scaley#=(GetSurfaceHeight()-60.0 )/getimageHeight(img_cache1)
            drawrotatedimage img_cache1,59,28,angle#,scalex#,scaley#,0,0,true 
            unlockbuffer
         

[baggey]

Hi Kevin

Thankyou for the tips. I shall be working through them!  ;)

I do have my routine working.

But some teething prob's need sorting! I seem to have a problem with writing to the screen and syncing from a function? Which sort of haves a very anoying flash effect.
Which could send you into a dribbling fit.  :P

My approach to solve this was make sure any screen and syncing operation happens within the main do.....loop!

While I'm really not understanding why you need to specifically program a routine to simulate loading,  as the emulation will do this anyway.  I'd just load the 'chunk of data'  into memory, render the page then copy it on in chunks..

The reason i need to do this is because im working with snapshots of the memory at the current time it was taken. Thus, the loading image will either already be loaded or lost!
If the emulator was to resive an external source, which scrolls through the memory. Yes we'd get the screen simulation anyways!

So

What im doing for each game is :-

  1 Selecting a game in the file system visually as well with the .scr
  2 We then have a choise, either load it or simulate the load.

I intend to have scr displayed, paused. Then game starts.
Or
I intend to have scr load simulated, paused. Then game starts.

The emulator would if i programmed, (mic input or microdrive input) to recive an external source. load that way! So it would behave as the original Spectrum did. But 5 to 8 mins for a load!
Im doing it instantaneously, whilst simulating the screen for that retro effect/feel!

Baggey