Author Topic: Help with greyscale tile engine? (Read 6819 times)

c4ooo · « **on:** April 09, 2015, 11:34:33 am »

So i was working in a grayscale tile engine, and i finished to the point where it works. Having made tiloe enginges in java before it was not even that hard. The problem is it is just to slow. So i have the code here:

Code: [Select]

Repeat getKey(41)
If getKey(1)
Y++
End
If getKey(2)
x--
End
if getkey(3)
x++
End
if getkey(4)
y--
End
RENDER()
DispGraph^RR
End
Return
Lbl Render
cLrDraw^RR
0->G 
For(E,0,H
for(D,0,w
Pt-Mask(D-x,E-y.{G+str1MAP}*16+Pic1TILES 
D+7->D
G++
End
E+7->E
End
Return

Now as ive said before, it works, but it is to slow for a platformer i had in mind, and the gray scale also looks bad. Is there any way i can speed it up? I have consired using Verticle and Horisontal to shift the buffer left/right/up/down when the player moves, but there is the problem that another entity could move while the player stands still. Any suggestions?

Runer112 · « **Reply #1 on:** April 09, 2015, 11:43:57 am »

Fully redrawing the map each frame is generally a bit to slow for the calculator. You're correct to suggest the shifting method to speed it up, and you were also correct to note the issue of sprites that don't move with the background.

The usual solution to this problem is to render only the map to a separate pair of screen buffers, allowing you to use the shift and minimal redraw method without worry, and copy the map to the main pair of screen buffers each frame before rendering sprites.

c4ooo · « **Reply #2 on:** April 16, 2015, 06:31:54 am »

Well, ok, then. I have that about using anther pair of buffers, but to me that seemed unoptimized(is unoptimized not in the English language?(i get a red line )). If it is the standard and best way, then ok thanks.

pimathbrainiac · « **Reply #3 on:** April 16, 2015, 07:24:42 am »

Just a quick optimization.

Quote

Code: [Select]
If getKey(1) Y++ End If getKey(2) x-- End if getkey(3) x++ End if getkey(4) y-- End

This can be optimized to:

Code: [Select]

x+getKey(3)-getKey(2)->x
y+getKey(1)-getKey(4)->y

Also that with what Runer said.

Sorunome · « **Reply #4 on:** April 16, 2015, 08:01:52 am »

Quote from: c4ooo on April 16, 2015, 06:31:54 am

Well, ok, then. I have that about using anther pair of buffers, but to me that seemed unoptimized(is unoptimized not in the English language?(i get a red line )). If it is the standard and best way, then ok thanks.

In this situation you want to optimize for speed, and almost always if you decrease the time a calculation needs you'll increase the size

c4ooo · « **Reply #5 on:** April 18, 2015, 08:20:34 am »

@pimathbrainiac I cant do that (now) because when a key is pressed i have to shift the buffers, and redraw part of a screen. $:-\$
@Sorunome Ive started using L1 and L4-415 as the second pair of buffers (if the number are not correct, just ignore 'couse i am writing this from memory). The biggest "un-optimized" problem i thought of is that ile have to do:

Code: [Select]

Buff(768)->str1B1 
Buff(768)->str1B2

,but my fear proved irrational.

Sorunome · « **Reply #6 on:** April 18, 2015, 09:44:51 am »

you can actually use L1 as a screen buffer, L4 as a second buffer, though, if you can't, don't use L4, and then L3 and L6 are the buffers which are drawn to the screen directly, giving you 3 - 4 screens.
The thing with L4 is that it destroys stat variables if you use it as a whole buffer, iirc.

c4ooo · « **Reply #7 on:** May 12, 2015, 07:12:39 am »

Well, ime going to revive this thread couse i might need some help. I got the engine to work bug free some time ago, but i jst cant get to be super fast. Its relatively fast, but ive seen some tile engines MUCH faster, also written in axe. one of these is Hayleia's tinycraft: https://www.omnimaga.org/ti-z80-calculator-projects/tinycraft-ii-(name-subject-to-change)/
If you look at the gif, it is VERY fast. (the gif even says "see full is useless, it is way to fast").
I am using partial redraw, and here is my code. I would appreciate if people would help optimize it. Or maybe my whole program structure should be changed... PS: both me and Hayleia in tinycraft use interrupt based greyscale.

Code: [Select]

...
Note: StrB1 and StrB2 are a pair of 765 byte buffers
...
lbl engine
128->w
64->h
RENDERALL()
Repeat getKey(41)
If getKey(1)
DOWN()
End
if getKey(2)
LEFT()
End
if getKey(3)
RIGHT()
End
if getkey(4)
UP()
End
Copy(StrB1,L6).copy tilemap buffer to display buffer
Copy(StrB2,L3)
...
other ui stuff to render
...
Gdisp().copy disp buffers to greyscale buffers
End
Return
Lbl RIGHT
Horizontal-(Str1B1)
Horizontal-(Str1B2)
x/8+6->D
x++
Y/8+5->J-9
Repeat ->E=J
RENTILE()
E+1
END
Return
Lbl LEFT
Horizontal+(Str1B1)
Horizontal+(Str1B2)
x++
x/8-6->D
Y/8+5->J-9
Repeat ->E=J
RENTILE()
E+1
END
Return
Lbl UP
Y--
Vertical+(StrB1)
Vertical+(StrB2)
WHLine(0,StrB2
WHLine(0,StrB2
y/8-4->E
x/8+7->I-13
Repeat ->D=I
RENTILE()
D+1
End
Return
Lbl Down
Vertical-(StrB1)
Vertical-(StrB2)
WHLine(63,StrB2
WHLine(63,StrB2
y/8-4->E
Y++
x/8+7->I-13
Repeat ->D=I
RENTILE()
D+1
End
Return
Lbl RENDERALL
...
sence t=this is only called once, not a spped issue
...
Return
Lbl RENTILE .renders tile (E,D)
Return!If {E*W+D+TILEMAPSTART}->C .return if tile = air
RetrunIf D<<0??E<<0>>(d+1)>>W??(E+1)>>H .return if (D,E) out of bounds
Pr-on(D*8-x+48->A,E*8-Y+32->B,C*16+TILESPRITESTART->C,StrB1
Pt-on(A,B,C+8
Return

Wow thats long...

Runer112 · « **Reply #8 on:** May 12, 2015, 09:34:27 am »

I tried the build of TinyCraft from the first post. That gif was definitely recorded with the program running at full speed, so that's a 2.5x speed boost. And I checked the screen update rate, which is only 30-40Hz; the proper update rate for "perfect" grayscale is about 60Hz. That gives it a 2x speed boost on top of the 2.5x for a total 5x more free CPU time than a "perfect" grayscale program running at normal speed.

For the Pokemon example I made for GrayLib, two simple tactics I used to boost the performance for the 83+ were to scroll two pixels per frame instead of just one and to use #ExprOn to request that Axe optimize for speed instead of size. These two together should make scrolling somewhere between 1.5x and 2x as fast.

Hayleia · « **Reply #9 on:** May 12, 2015, 01:27:03 pm »

Quote from: Runer112 on May 12, 2015, 09:34:27 am

I tried the build of TinyCraft from the first post. That gif was definitely recorded with the program running at full speed, so that's a 2.5x speed boost.

Well depends on if he's talking about the first part of the gif (where I explicitedly state that it's 15MHz and it's too fast) or the second part (which is 6MHz).
And that message at the beginning doesn't mean "Full is useless, it's too fast without it", but "Full is useless, it's too fast with it so let's remove it"

Sorry if it was not clear.

c4ooo · « **Reply #10 on:** May 13, 2015, 06:34:13 am »

Quote from: Runer112 on May 12, 2015, 09:34:27 am

scroll two pixels per frame instead of just one

This seems an "artificial" way to speed things up, but the results are still relatively smooth to the user. Using

Quote from: Runer112 on May 12, 2015, 09:34:27 am

use #ExprOn to request that Axe optimize for speed instead of size.

Forgot about that command

thanks for reminding me

Quote from: Runer112 on May 12, 2015, 09:34:27 am

I tried the build of TinyCraft from the first post. That gif was definitely recorded with the program running at full speed, so that's a 2.5x speed boost. And I checked the screen update rate, which is only 30-40Hz; the proper update rate for "perfect" grayscale is about 60Hz. That gives it a 2x speed boost on top of the 2.5x for a total 5x more free CPU time than a "perfect" grayscale program running at normal speed.

I made it so i can easily change from greyscale to b&w. *canges to B&W*
Without interrupts speed is tremendously increased. Thanks for the to tips @Runer112!

Quote from: Hayleia on May 12, 2015, 01:27:03 pm

Quote from: Runer112 on May 12, 2015, 09:34:27 am
I tried the build of TinyCraft from the first post. That gif was definitely recorded with the program running at full speed, so that's a 2.5x speed boost.
Well depends on if he's talking about the first part of the gif (where I explicitedly state that it's 15MHz and it's too fast) or the second part (which is 6MHz).
And that message at the beginning doesn't mean "Full is useless, it's too fast without it", but "Full is useless, it's too fast with it so let's remove it"
Sorry if it was not clear.

As to the miscoption, i understood what you where trying to say

Also, may i take a peek at your tile mapping code to see if there is any thing else i can improve in mine? If you happen to have a backup of the code to the first tiny craft build that would be awesome!

Author Topic: Help with greyscale tile engine? (Read 6819 times)

c4ooo

Help with greyscale tile engine?

Runer112

Re: Help with greyscale tile engine?

c4ooo

Re: Help with greyscale tile engine?

pimathbrainiac

Re: Help with greyscale tile engine?

Sorunome

Re: Help with greyscale tile engine?

c4ooo

Re: Help with greyscale tile engine?

Sorunome

Re: Help with greyscale tile engine?

c4ooo

Re: Help with greyscale tile engine?

Runer112

Re: Help with greyscale tile engine?

Hayleia

Re: Help with greyscale tile engine?

c4ooo

Re: Help with greyscale tile engine?