Eric: The Mysterious Stranger - RTS game(WIP)

[Boromir]

So, you need to sort everything each frame?

Yes, I suppose that's potential for optimization.

[leopardpm]

So, you need to sort everything each frame?

Yes, I suppose that's potential for optimization.

yes, but in a different way... no more sorting at all - everything just draws correctly... its pretty nifty.

What is the size of the tile display, 30 tiles by 30 tiles or what?

How do you sort, by just the y-value or by both X & Y coords of the tile in question?

[Boromir]

yes, but in a different way... no more sorting at all - everything just draws correctly... its pretty nifty.

What is the size of the tile display, 30 tiles by 30 tiles or what?

How do you sort, by just the y-value or by both X & Y coords of the tile in question?

Tile size is (32x(16+(16 extra space)))
I only sort by Y.

[leopardpm]

Tile size is (32x(16+(16 extra space)))

is this the size of the tile map on screen? so there are 32 tiles across and 32 tiles down?

Here is a demo I made which highlights the principle of what I call 'Alpha Z-Sorting', it uses the screen pixel alpha value as a storage place for the layer of the pixel (0-255 layers)... the alpha on the screen is not used for anything (I think) so I thought I would put it to use. This demo shows the fundamental idea, but when completely fleshed out it is pretty awesome, and wicked fast. This demo has two major slow downs: no page flipping and the whole erasing bit... those both get thrown away in reality...

NOTE: Cleaned up code a bit

Code: Select all

Function Behind ( ByVal source_pixel As UInteger, ByVal destination_pixel As UInteger, ByVal parameter As Any Ptr ) As UInteger
    If destination_pixel shr 24 < source_pixel shr 24 Then
        Return source_pixel
    Else
        Return destination_pixel
    End If
End Function

    dim as integer fps, lastx
 
    ScreenRes 320, 200, 32

    color ,rgba(0,0,0,255)   '<---the alpha here sets the background black to be the FOREMOST layer

    Dim img As Any Ptr = ImageCreate( 32, 32, RGBA(255, 0, 255,0) )

        Circle img, (16, 16), 15, RGBA(255, 255,   0,  10),     ,     , 1, f   ' notice how different parts of smiley
        Circle img, (10, 10), 3,  RGBA(  0,   0, 255, 200),     ,     , 2, f   ' have different alpha levels.... the eyes have alpha 200
        Circle img, (23, 10), 3,  RGBA(  0,   0, 255, 200),     ,     , 2, f
        Circle img, (16, 18), 10, RGBA(  0,   0, 255, 100), 3.14, 6.28         ' the mouth has alpha 100, his body(circle) has alpha 10

    Dim imgErase As Any Ptr = ImageCreate( 32, 32, RGBA(0, 0, 0,0) )
   
   dim as integer x = 1, dx = 1

' Draw the screen ONCE:
    cls
'' set up the screen with background colors, different alphas (z-levels)
screenlock
    line (1,15)-(155,200),rgba(0,0,255,0),bf       '<---- alpha 0 sets the blue box to the Back layer
    line (165,15)-(320,200),rgba(255,0,0,128),bf   '<---- alpha 128 sets the red box to be a middle layer

    line (1,15)-(155,200),rgba(0,0,255,0),bf       '<---- alpha 0 sets the blue box to the Back layer
    line (65,15)-(95,200),rgba(0,0,255,255),bf     '<---- alpha 255 sets a blue hidden window to the front layer

    line (165,15)-(320,200),rgba(255,0,0,128),bf   '<---- alpha 128 sets the red box to be a middle layer
    line (250,15)-(285,200),rgba(255,0,0,0),bf     '<---- alpha 0 sets a red hidden window to be the Back layer
'                                                     but it is RED, just like the red box around it, but different Alpha so can't see this 'window'
'                                                     but also this box is ALWAYS in the background because Alpha = 0
screenunlock



    get (x, 100)- step (31,31), imgErase ' initialize the erase image
' Main Loop Here... Note: NO CLS, NO redrawing of 'background'
do
    screenlock
        Put (x, 100), imgErase,pset ' erase previous smiley with whatever was there before him...
        x += dx
        get (x, 100)- step (31,31), imgErase ' get the new background erase image at the new x coord
        Put (x, 100), img, custom, @Behind ' put smiley face on screen
        if x < 2 or x > 286 then dx = -dx   ' change direction when near edge of screen
    screenunlock
    sleep 1
loop until inkey <> ""

ImageDestroy img
ImageDestroy imgErase

end

[Boromir]

Tile size is (32x(16+(16 extra space)))

is this the size of the tile map on screen? so there are 32 tiles across and 32 tiles down?

The actual amount of tiles changes depending on the screensize and camera size.

Here is a demo I made which highlights the principle of what I call 'Alpha Z-Sorting', it uses the screen pixel alpha value as a storage place for the layer of the pixel (0-255 layers)... the alpha on the screen is not used for anything (I think) so I thought I would put it to use. This demo shows the fundamental idea, but when completely fleshed out it is pretty awesome, and wicked fast. This demo has two major slow downs: no page flipping and the whole erasing bit... those both get thrown away in reality...

Won't this mess up 32 bit graphics?

[leopardpm]

The actual amount of tiles changes depending on the screensize and camera size.

that makes things trickier, but still possible

Won't this mess up 32 bit graphics?

nope... not in any test that I have done... the alpha on the screen page isn't used... when you PUT an image it will take THAT IMAGE'S alpha into account for blending with the background... test it out, see if you can see a problem...

[Boromir]

Code: Select all

Function Behind ( ByVal source_pixel As UInteger, ByVal destination_pixel As UInteger, ByVal parameter As Any Ptr ) As UInteger
    If destination_pixel shr 24 < source_pixel shr 24 Then
        Return source_pixel
    Else
        Return destination_pixel
    End If
End Function

This would have to be alpha aware, right?

Edit: Did a quick test with a 32 bit bmp and the alpha areas both aren't blended due to the use of custom and the alpha pixels are used for the depth sorting.

[leopardpm]

it is...

Code: Select all

If destination_pixel shr 24 < source_pixel shr 24 Then

that tests the alpha.... destination pixel and source pixel are 32 bit integers.....

[Boromir]

Code: Select all

Function alpha2(ByVal source_pixel As UInteger,ByVal destination_pixel As UInteger,ByVal parameter As Any Ptr) As UInteger
    Dim As single r,g,b,a,r2,g2,b2,a2,r3,g3,b3,a3
    r=cR(source_pixel):g=cG(source_pixel):b=cB(source_pixel):a=cA(source_pixel)
    r2=cR(destination_pixel):g2=cG(destination_pixel):b2=cB(destination_pixel):a2=cA(destination_pixel)
    
    r2=r2*a2:g2=g2*a2:b2=b2*a2
    r =r *a :g =g *a :b =b *a
    
    a3=a+(a2*(1-a/255))
    r3=((r+(r2*(1-a/255)))/a3)
    g3=((g+(g2*(1-a/255)))/a3)
    b3=((b+(b2*(1-a/255)))/a3)
    
    Return RGBA(r3,g3,b3,a3)
End Function

There is an alpha aware custom method I made once.

[leopardpm]

Have fun! I am sure you are starting to see how you can incorporate the Y value (take the Y screen coord of the tile and divide by 2 for resolutions up to 512 height... divide by 3 for up to 768... divide by 4 for up to 1024, etc..... ) and store it into the screen with another custom PUT routine... I have it on the forum somewhere in a demo in a thread with BasicCoder, I forgot what the thread was about.... I will see if I can find the original program...

I think this is it: http://www.mediafire.com/file/u7b58au2n ... 282%29.zip

it does have a graphical glitch... the goblins 'disappear' sometimes... I stopped playing with it before I had debugged that glitch.... but I think the custom PUT with alpha is used...

You can click on the map to move the view and do some other things... I think we were testing A-Star pathing overall....

There is an alpha aware custom method I made once.

That looks like a blending routine...

[Boromir]

That looks like a blending routine...

Yes, what I'm confused about his how you can use the alpha value for both blending and z-sorting?

[leopardpm]

That looks like a blending routine...

Yes, what I'm confused about his how you can use the alpha value for blending and z-sorting?

well, first off, you don't 'need' to use the alpha for your z-sort... it is just convenient... we could just make up a 2D array of ubytes (or double ubytes so you don't have to 'divide' the y-value to fit...) and access that instead...
but try this test: make a full screen of all same color (like RED (255,0,0)), make half of it alpha = 255 and the other half alpha = 0, then try PUTting an alpha image into both halves and see if you can detect a difference....

[Boromir]

see if you can detect a difference....

Well, I get a bad effect with smooth alpha gradients, the z sorting seems to interfere.

EDIT: Also, what is the benefit of per pixel? Why not per tile?

[leopardpm]

can you post your test code?

even so, as I said, it is only convenient to use the alpha... not necessary.

why per pixel? because basically it is a pixel perfect collision detector.... each pixel has the same z-level as the entire tile, but you check per pixel because it is the individual pixels that overlap.... i am not saying it very clearly though.. will post some more tomorrow evening... gotta sleep now

was looking through my code for that World Sim demo and here is a more involved Z-Alpha version:

Code: Select all

Function TransZalpha ( ByVal src_pix As uinteger, ByVal dest_pix As uinteger, ByVal param As Any Ptr ) As uinteger
    '
    ' Instead of the alpha holding the z-level, it now holds the index to the ViewIndex array, defined as follows:
    '
    'type ViewMapIndexinfo
    '    as integer  spriteType    ' this is: 1 = agent, 2 = world terrain
    '    as integer  spriteIndex   ' the index of the sprite type (ie: if spriteType = 1 (agent), then this value will be the Agent number
    '    as integer  spriteZlevel  ' the Z-Level of the sprite (screen Y value)
    '    as byte  wMapX         ' world map x location
    '    as byte  wMapY         ' world map y position
    'end type
    '
    'dim shared as ViewMapIndexinfo VMI(255)  ' only 0-255 possible values in the alpha channel...
    '    
    Dim As ubyte Ptr para
    dim as uinteger src_Alpha 
    dim as single shadeval
    dim as ubyte R, G, B, Src_VMI_Index, dest_VMI_Index
    dim as integer Src_Z_Level, Dest_Z_Level

    src_Alpha = src_pix and &hff000000   ' save the alpha of source pixel for use to make shadows....
                                         ' or later to do both shadows AND have transparent effects like
                                         ' with windows or water or fog/steam/smoke....
    src_pix   = src_pix and &h00FFFFFF   ' strip out alpha from source pixel, retain pixel RGB color

    If (src_pix = &h00FF00FF) or (src_Alpha = &h00000000) Then       ' if is magic pink mask OR src alpha is 0 then return the Destination(background) pixel unaltered
        Return dest_pix
    else
        para = Cast(ubyte Ptr, param)  ' para is the parameter passed to the PUT routine
        Src_VMI_index = *para
        Src_Z_Level = VMI(Src_VMI_index).spriteZlevel     'figure out the source pixel's Z-Level value
    
        dest_VMI_Index = dest_pix shr 24      '<---- Get the Dest Pix Alpha as an index to the sprite info
        dest_Z_Level = VMI(dest_VMI_index).spriteZlevel   'figure out the destination pixel's Z-Level value
        
        If (dest_Z_Level < Src_Z_Level) then          ' Only plot source pixel if z-level of sprite is higher than destination
            ' CURRENT VERSION:
            ' This routine will shade (darken) the dest pixel according to
            ' the alpha of the src pixel (has nothing to do with the Z-Level)
            '
            ' FUTURE VERSION:
            ' Here is where need to blend src color and dest color based on Src_Alpha... 
            ' basically the 'alpha' setting of src PUT image - this would make routine more
            ' versatile and able to have z-ordered sprites WITH alpha shadows AND able
            ' to also use magic pink mask as well!!!! One routine to bind them all....
            '              NEW = alpha * SRC + (1 - alpha) * DEST
            ' Where: NEW, SRC and DEST are RGB colors, and alpha is a floating point number in the range [0,1].
            '
            if Src_Alpha = &hff000000 then
                src_pix = (Src_VMI_index shl 24) or src_pix  ' full alpha so store the VMI index into the alpha
                Return src_pix
            else                                             ' We have an alpha shading going on now... 
               shadeval = (1-((Src_Alpha shr 24) / 255))         ' create a percentage (value between 0 and 1) from the src pixel alpha
               'dim as ulong pix32 = 0                       ' having shadows and thus doing these calculations
               R = RGBA_R(dest_pix) * shadeval               ' will slow down the PUT routine quite a bit, 
               G = RGBA_G(dest_pix) * shadeval               ' but is still usable for our purposes
               B = RGBA_B(dest_pix) * shadeval
               src_pix = RGBA(R, G, B, dest_VMI_index)        '<--- put shaded color and sprite VMI index in here! **** potential issue? should be Source pix Index, right?  except this pixel IS the Dest pix shaded by the source pic, so maybe this is correct...
               return src_pix
            end if
        Else
            return dest_pix
        End If
    end if
End Function

looks like I was on the road to incorporating the alpha of the source image for blending, using the parameter passed by the PUT statement as a sprite index #...

There look to be a couple of issues that I don't like: first off the VMI() array holds the sprite info for only the sprites on screen, this changes, so that means this array needs to be constantly updated (pain in butt and a bit of a time suck). These routines do not 'erase' at all yet, so they are not part of my 'final vision' for a speed demon sprite/terrain manager... this was more an intermediate attempt at a simple way to do z-ordered sprites without sorting... The problem I also didn't address is with larger sprites(wider than one tile, like your houses...) and proper overlap... that will take even more trickiness to deal with...

[leopardpm]

Boromir, in this image I see the house is multiple tiles wide... what happens when a sprite character is just below the far right corner of the house? I mean, the house is sorted by its y-value (I assume the bottom of the image) so it should be block or overlap anything that has a lesser y-value...like a character just south of the far right corner... OR, did you divide the house into multiple images, one for each tile width so they get drawn properly? That is one solution (I hate it though) to deal with the 'wide sprite' problem of isometric display...

Another way to deal with it through my Trans-Alpha routine might be to have each column of pixels in the src sprite have its own z-level, figured out 'somehow'... but I don't like that either... very messy and time-consuming... I am having a mental block on finding an easy and speedy way to deal with this issue...