Eric: The Mysterious Stranger - RTS game(WIP)

[Boromir]

Ah, yes. I remember the issue. It's been a while since I've worked in the rendering code but I remember doing something to get it working. Couldn't say how the efficiency stands up. It's all to do with the "jy2" comparisons.

Code: Select all

sub render(tiles() as tile,agents() as agent,cam As camera)
Line cam.vscreen,(0,0)-(cam.w,cam.h),rgb(100,0,0),bf
dim as integer i,jy2,vv1,vv2,v1=cam.vy-th, _
			   v2=cam.vy+cam.h,v3=cam.vx-tw, _
			   v4=cam.vx+cam.w,v5=cam.vx-tw3, _
			   v6=cam.vx+cam.w+tw3
for i=0 to numtiles
    if tiles(i).phy>v1 andalso tiles(i).phy<v2 andalso _
       tiles(i).phx>v3 andalso tiles(i).phx<v4 then
		If tiles(i).picref>-1 Then tiles(i).drawr(tiles(i).picref,0,cam,1)
		If tiles(i).picref2>-1 Then tiles(i).drawr(tiles(i).picref2,0,cam,1)
    end if
next

for jy as integer=cam.vy-120 to cam.vy+cam.w step (twhh)
    jy2=jy-(jy mod twhh):vv1=jy2+thh:vv2=jy2+th
	for i=0 to numtiles
		if tiles(i).picref3>-1 andalso (tiles(i).phy-tiles(i).offy)=jy2 andalso _
		   tiles(i).phx>v5     andalso tiles(i).phx<v6 then _
				tiles(i).drawr(tiles(i).picref3,0,cam,0)
	next

    for i=0 to numagents
        if agents(i).phy+thh>=vv1 andalso agents(i).phy<vv2 andalso _
           agents(i).phx>v3       andalso agents(i).phx<v4 then _
				agents(i).drawr(agents(i).direc+(agents(i).imgref*8),1,cam)
    next
next
end sub

[BasicCoder2]

It's been a while since I've worked in the rendering code but I remember doing something to get it working.

Did you figure out the vanishing legs near the sunken water issue?
At the moment I am sticking to the 2D view until I have enough of the logic worked out before I worry again about how to render it as an isometric display and drawing all those isometric images. The issue I remember having was the fact agents straddled tiles.
It would be interesting if you could use English and visual explanations as to how you render the scene :)
https://shaunlebron.github.io/IsometricBlocks/
.

[leopardpm]

ah, ok.... I think I understand, but will look at the code more in a bit

[Boromir]

Did you figure out the vanishing legs near the sunken water issue?

I believe that was a map design issue not a rendering fault. Either way it's not there any more.

At the moment I am sticking to the 2D view until I have enough of the logic worked out before I worry again about how to render it as an isometric display and drawing all those isometric images. The issue I remember having was the fact agents straddled tiles.
It would be interesting if you could use English and visual explanations as to how you render the scene :)

Mine is not the best method, just uses a Y value that increments from top to bottom drawing anything with the same Y value. Currently it's limited to squares. The link you posted has a better method that I'm considering using instead.

[leopardpm]

The link you posted has a better method that I'm considering using instead.

I definitely think z-buffering is better than what the link proposes.... too many 'special cases'... there is only 1 'special case' for z-buffering and that is when an object is wider than a single tile since the entire object 'inherits' the y-value of its lowest point... all that needs done is for each horz tile-width strip to inherit the bottom-most tiles y-value... then all is well.... easier said then done though... still thinking on this.

I avoided this issue altogether because my basic design was with 'cubes' (the way you don't like) instead of flat tiles. In this way I 'built' multi-tiled objects.... but, this way also comes with a performance loss because instead of one big image blit (house, for example), there would be 9 or more tile-sized blits... much slower for larger objects... I don't like that... still thinking for a way to deal with the issue and use larger sprites for performance.

[leopardpm]

just thinking out loud here:
I notice a few things... the issue will not really occur with larger 'characters' as they are generally columns... oops, wrong, just thought of monsters like a giant scorpion or long worm-like thing....

ok, next thought... whatever calcs need to be made MUST be made outside of the custom PUT routine or else major performance hit... in fact, the calcs should all be pre-calced before the entire game loop, and therefore associated with each sprite at load time. This could be done with a simple 1-Dim array which has the offset from the images lowest y-value for each column of pixels in the image... this offset would be automatically added to the y-value when assigning the z-buffer value for each pixel...

hmmm....

[BasicCoder2]

The link you posted has a better method that I'm considering using instead.

The posted link was not so much for its content as for an illustration how to explain an algorithm. In theory code should be sufficient and is also proof of a solution but in practice untangling other people's code is difficult for some and also we really program from top down. Take Bresenham's line drawing algorithm for example. Easy to explain with pictures and some simple equations at a high level that we all understand. Then you can translate that down into what language you are using and also understand but which someone else may not be familiar with. Even if they are familiar with the language the high level explanation is still easier to understand, IMHO. Understanding it if required also means you can modify it. For example turn it into a line drawing algorithm with origin, length and angle. drawLine (x1,y1,length,angle,penSize,penColor)
.

[leopardpm]

ok, going down a bit of a rabbit hole here but...

It appears to me that to do what I want when PUTting an image, I will have to write my own PUT routine. The bad thing about this is that last time I delved into doing so, the resulting routine took about 5 times longer than the standard PUT(with pset).... BUT, in all our discussion in the other thread about compression etc, I think I can combine 'a bit' of compression (use RLE but only on the fully transparent pixels) on the image and make a PUT routine that will use that image to blit to the screen faster than having to touch every pixel (can skip touching all the RLE transparent pixels...). Here is the trick:

A fully transparent pixel has 3 bytes of unused info (RGB), this means I can test the Alpha to see if it is 0, and if so, then treat the RGB values as X & Y offsets within the image to where to 'jump' to to start plotting the next non-trans pixel. The RLE won't compress the image storage space down much (that is not its purpose anyways here), but it will allow this transparent space 'skipping' which will make the blitting faster (hopefully, in theory...).

The image format I am thinking of has standard pixel values, EXCEPT, when a transparent pixel is encountered (alpha=0), then the R of that pixel specifies the X coord(0-255 max) & the G specifies the Y coord(0-255 max) of the next pixel in the image - the routine just skips ahead... all the other pixels won't be RLE or changed in any way... hmm still have the B component of the transparent pixel available for even more trickiness, but I can't think of how to use it... it 'could' say how many colored pixels are coming up so I could then use the 'memcpy' command to wholesale pset them... would be limited to 255 pixels though... interesting....

having a max limit image size of 255 x 255 is not much of a problem, I think... or is it? Wonder how big Boromir's 'house' is? looks to be only about 100 x 100 pixels... so great!

sorry about my mental musings here, it helps me to type things out as I figure stuff out and folks can see how I might have derived an algo or see a potential problem that I missed in my thinking...

[Boromir]

having a max limit image size of 255 x 255 is not much of a problem, I think... or is it? Wonder how big Boromir's 'house' is? looks to be only about 100 x 100 pixels... so great!

My house is about 100x120. Btw, I've gotten my render routine speed up to snuff. Getting about 200 fps now. That should be more than enough. Now I think I need to work on optimizing my pathfinding routine.

[leopardpm]

Btw, I've gotten my render routine speed up to snuff. Getting about 200 fps now.

wait a second, sparky! What did you do? please share! lol

last we left off when doing speed tests, you said this:

Ok, I'm getting about a 5 fps increase for using 2 pages and pre-calculating all those values.
With AI on: I get 100 fps with no rendering performed and 50 fps with rendering.
With AI off: I get 670 fps with no rendering performed and 80 fps with rendering.
Still have to test my 1.80 ghz laptop.

NOW you are up to 200 fps... with or without AI? with or without rendering? in any case, even jumping from 100 fps (AI on, no render) to 200 fps is a pretty big jump! What happened?

[Boromir]

NOW you are up to 200 fps... with or without AI? with or without rendering? in any case, even jumping from 100 fps (AI on, no render) to 200 fps is a pretty big jump! What happened?

With AI on: I get erratic fps.
With AI off: I get 670 fps with no rendering performed and 200 fps with rendering.

In the first numtiles loop it finds and draws on screen ground tiles.
So in the next numtiles loop, instead of recalculating onscreen tiles I have an array that remembers the onscreen ones.
It's very simple but saves a lot of time. The idea was suggested to me by another programmer.

Code: Select all

sub render(tiles() as tile,agents() as agent,cam As camera)
Line cam.vscreen,(0,0)-(cam.w,cam.h),rgb(100,0,0),bf
dim as integer ks(9999),rr
dim as integer i,jy2,vv1,vv2,v1=cam.vy-th, _
			   v2=cam.vy+cam.h+130,v3=cam.vx-tw-32, _
			   v4=cam.vx+cam.w+32
for i=0 to numtiles
    if tiles(i).phy>v1 andalso tiles(i).phy<v2 andalso _
       tiles(i).phx>v3 andalso tiles(i).phx<v4 then
		If tiles(i).picref>-1 Then tiles(i).drawr(tiles(i).picref,0,cam,1)
		If tiles(i).picref2>-1 Then tiles(i).drawr(tiles(i).picref2,0,cam,1)
		ks(rr)=i:rr+=1
    end if
next
ks(rr)=-2
rr=0
for jy as integer=cam.vy-120 to cam.vy+cam.w step (twhh)
    jy2=jy-(jy mod twhh):vv1=jy2+thh:vv2=jy2+th
	do
	if ks(rr)=-2 then exit do else i=ks(rr):rr+=1
		if tiles(i).picref3>-1 andalso (tiles(i).phy-tiles(i).offy)=jy2 then _
				tiles(i).drawr(tiles(i).picref3,0,cam,0)
	loop
	rr=0
    for i=0 to numagents
        if agents(i).phy+thh>=vv1 andalso agents(i).phy<vv2 andalso _
           agents(i).phx>v3       andalso agents(i).phx<v4 then _
				agents(i).drawr(agents(i).direc+(agents(i).imgref*8),1,cam)
    next
next
end sub

[leopardpm]

In the first numtiles loop it finds and draws on screen ground tiles.
So in the next numtiles loop, instead of recalculating onscreen tiles I have an array that remembers the onscreen ones.
It's very simple but works very good. The idea was suggested to me by another programmer.

ok, I understand pre-calcing the positions (basically), but, there is something wrong with your implementation...
first, you are not doing any pre-calc - what you are currently doing is just remembering which tiles are on-screen... this only is saving you the time it takes to test all the tiles for being on-screen or not (which could be alot of tiles, so it does save time...) BUT, more issues coming, or at least optimizations... hold on, need to understand exactly what you are doing in this routine...

[Boromir]

ok, I understand pre-calcing the positions (basically), but, there is something wrong with your implementation...
first, you are not doing any pre-calc - what you are currently doing is just remembering which tiles are on-screen... this only is saving you the time it takes to test all the tiles for being on-screen or not (which could be alot of tiles, so it does save time...) BUT, more issues coming, or at least optimizations... hold on, need to understand exactly what you are doing in this routine...

Well, I'm always looking for more ways to optimize. :)
I just did some optimizations to my pathfinding routine but it's still not the best for 100 soldiers. Still got to keep squeezing it. I have one idea that should reduce the number of times it's called.

I also added a bare bones combat system.

[leopardpm]

Well, I'm always looking for more ways to optimize. :)

I am getting side-tracked on my RLE blit routine... once I get some results then I will come back and look better at your code here...

I just did some optimizations to my pathfinding routine but it's still not the best for 100 soldiers. Still got to keep squeezing it. I have one idea that should reduce the number of times it's called.

that is always good!

I also added a bare bones combat system.

oh YAY! I know you don't like posting your source code, but can you make an .exe so I can play too?! I want to see your combat stuff!

[Boromir]

I am getting side-tracked on my RLE blit routine... once I get some results then I will come back and look better at your code here...

RLE blit sounds interesting. I'm assuming the goal is to obtain speed?

I also added a bare bones combat system.

oh YAY! I know you don't like posting your source code, but can you make an .exe so I can play too?! I want to see your combat stuff!

I don't mind posting code but I think it's more efficient to have the game on google drive due to its size.(and it uses images and data files)
I will upload my latest version as soon as I can get to work on windows. I must be doing something wrong because my game runs on linux but crashes on Windows.
Combat is just a chain reaction right now. If I attack an enemy with my player that agent will fight back. If he wins he hunts down another enemy and the process starts over. Winners keep hunting new enemies until only one side is left. I plan to change this to more intelligent behavior soon.

The fsm is probably the sloppiest bit of code in my game. I'm considering looking in to goap again.