Dark Bit Factory & Gravity
ARCHIVE => Archive => Cobra => Topic started by: Shockwave on February 28, 2007
-
Sorry about this, knocked up quick as a test, but for some reason it runs fucking slow!
I must have done something to screw this up...
// RASTER EFFECT BY SHOCKWAVE.
// ---------------------------
// FEBRUARY 2007.
// LAME I KNOW, BUT FROM LITTLE ACORNS ETC....!!!! 11
//----------------------------------------------------------------------------------------------------------------------------------
PROGRAM USES PURE2D, KEYSET
//----------------------------------------------------------------------------------------------------------------------------------
CONST XRES = 800
CONST YRES = 600
VAR
GADD : REAL =0
GADD2: REAL =0
GADD3: REAL =0
//----------------------------------------------------------------------------------------------------------------------------------
PROCEDURE INITIALISE()
BEGIN
OPENSCREEN( XRES , YRES)
END
//----------------------------------------------------------------------------------------------------------------------------------
PROCEDURE RASTERS()
VAR
Y : INTEGER
RD,GR,BL : REAL
BEGIN
FOR Y=0 TO YRES-1
RD = 125+((SIN(Y+GADD3)*50)+(COS(Y+GADD2)*50)-(SIN(Y+GADD)*24))
GR = 125+((SIN(Y+GADD2)*50)+(COS(Y+GADD)*50)+(SIN(Y+GADD3)*24))
BL = 125+((SIN(Y+GADD)*50)-(COS(Y+GADD3)*50)-(SIN(Y+GADD2)*24))
LINE (0,Y,XRES,Y,TORGBA(RD,GR,BL,255))
NEXT
END
//----------------------------------------------------------------------------------------------------------------------------------
// MAIN PROGRAM
//----------------------------------------------------------------------------------------------------------------------------------
BEGIN
INITIALISE()
WHILE NOT KEYDOWN (VK_ESCAPE)
GADD=GADD+1
GADD2=GADD2+2
GADD3=GADD3+3
RASTERS()
FLIP
WEND
END
//----------------------------------------------------------------------------------------------------------------------------------
-
150fps here.
Out of interest, what sort of speed would you expect for a routine like this ?
for comparison, A raw loop with just 'cls' under software in cobra will run around 150fps (on this machine)
*Edit* just ported this to be 'cobra2d' friendly (IE. use code which works in software and 2d in 3d mode) Same size, runs at aprox 3000fps using hardware on this machine.
-
In software I was looking for somewhere around 500 - 800fps. As they are horizontal lines I was expecting more speed.
-
Here is the FB software rendered version, running at about 880 fps.
' THIS IS WHY COBRA NEEDS >>REAL AND **NOT** FAKE ASM << ALSO TO SHOW HOW FAST
' HORIZONTAL LINES SHOULD BE IN SOFTWARE.
'-------------------------------------------------------------------------------
' REMOVE COMMENT ON LINE BELOW FOR WINDOWED MODE
#DEFINE PTC_WIN
#INCLUDE "TINYPTC.BI"
' ALL VARIABLES MUST BE DECLARED.
' -------------------------------
OPTION STATIC
OPTION EXPLICIT
CONST PI AS DOUBLE = 3.1415926535897932
' SCREEN DIMENSIONS.
' ------------------
CONST XRES = 640:' WIDTH
CONST YRES = 480:' HEIGHT
DECLARE SUB COPERASE()
DIM SHARED AS DOUBLE OLDTIME
DIM SHARED AS INTEGER TICKS
DIM SHARED AS INTEGER FPS
DIM SHARED AS UINTEGER BUFFER ( XRES * YRES )
If( PTC_OPEN( "S!P", XRES, YRES ) = 0 ) Then
End -1
End If
OLDTIME=TIMER
'-------------------------------------------------------------------------------
' THE MAIN LOOP;
'-------------------------------------------------------------------------------
DIM SHARED GADD AS DOUBLE
DIM SHARED GADD2 AS DOUBLE
oldtime = timer
while (1)
gadd=gadd+1
gadd2=gadd2+3
PTC_UPDATE @ BUFFER (0)
COPERASE()
TICKS=TICKS+1
IF TIMER-OLDTIME>=1 THEN
FPS = TICKS
print str(FPS)
TICKS=0
OLDTIME=TIMER
END IF
wend
'-------------------------------------------------------------------------------
' THE MAIN LOOP ENDS HERE.
'-------------------------------------------------------------------------------
SUB COPERASE()
DIM Y AS UINTEGER
DIM PP AS UINTEGER PTR
DIM TCR AS UINTEGER
DIM TCG AS UINTEGER
DIM TCB AS UINTEGER
DIM TC AS INTEGER
DIM SLICE AS UINTEGER
FOR Y=0 TO YRES-1
SLICE=XRES
TCR=160+(45*SIN((y+GADD2)/143)+15*COS((y+GADD)/13)-8*COS((y+GADD2)/29))
TCG=160+(45*SIN((y+GADD2)/133)+15*COS((y+GADD)/13)-8*COS((y+GADD2)/29))
TCB=160+(45*SIN((y+GADD2)/123)+15*COS((y+GADD)/13)-8*COS((y+GADD2)/29))
TC=RGB(TCR,TCG,TCB)
PP = @BUFFER(Y*XRES)
asm
mov eax,dword ptr[TC]
mov ecx, [slice]
mov edi, [PP]
rep stosd
end asm
NEXT
END SUB
This is why you need to include pointers and asm into cobra.
-
Nice, thanks.
And yes, message received and understood.
I'll do some further tuning, and see if / when I can open up the asm side of things.
The main reason for delaying it, is that the current method I have dumps the assembler code right into the stream with the generated assembler, I want to make it a little more 'part' of the language so that it will syntax check it, rather than relying on the final assembler (which doesn't link back to a line number etc.
If you want to have a go 'as it is, warts and all' I'll try and open that functionality in a patch or so's time (won't be this weekend, as I try and code freeze on a thursday for testing).
-
Thanks Graham.
You know, really speaking it is only that little tiny slice of asm that I mostly use. I use it whenever I need to rasterise anything, you wouldn't believe how much it speeds things up.
After I wrote this I was thinking that perhaps it might even be the alpha component of the 2D graphics commands that can also slow things down.
Would it be a pain to have non-alpha'ed versions of the commands?
This could give the 2D command set a great speed boost, with the alpha versions of the commands available to those who want them of course :)
The main thing has got to be pointers though. They would be so much more useful than asm even. I use them all the time now, it's kind of strange programming without them.
I'm going to have a go at making something else in a little while. I figure that if I can build up a few stock routines in here to do things like scrolling, starfields, vectors etc then people will be able to use them to learn.
Cheers Graham, I appreciate what you're doing here.
-
Not a problem matey...
Loosing alpha doesn't really speed things up much as the 2d side of thing is optimized for 32bit read/writes, so everything 'really' uses alpha, even when it doesn't ;)
It would certainly be good to have examples of the sort you are describing, and I'll see what I can sort out with the pointers etc.
-
Ok. Well, the examples will have to be written in Freebasic, is that ok?
I think that Seeve Elliott from your place wanted pointers too? I think he wanted them to be more C++ Style..
-
yeah, go for it, then I can port them over and use it as a test for optimizing...
-
Here's part 1 (http://dbfinteractive.com/index.php?topic=1453.0)
That's the first example.
It runs at 850 fps here. Exe attached to this post for your purposes.
-
Yay ;)
program
var
tc:integer
begin
tc = 1
MessageBox('before tc='+tc)
asm
mov eax,!tc
mov edx,[!tc]
add edx,1
mov [eax],edx
(* yes I know this can be reduced to the following, just checking a few commands ;)
add [!tc],1
*)
endasm
MessageBox('after tc='+tc)
end
Well, it's a start :)
-
Sweet! You know what, a lot of people look at the list of specifications before they buy a language, and this will be one that might decide for a few people. Even if they never use it, some people like to know that the language they chose can do stuff like this.
Also it will give the fanboys something to argue about on some of the forums :D
For me though it will mean that I can at least write some nice fast copper effects :)
-
Grr, hit a snag (one of the reasons I used the old method I had), keyword clashes with the core language.
With the current parser, it's difficult to get it to ignore 'internal' keywords.
How much of a pain in the ass would it be to use it in this form ?
program
var
tc:integer
t1,t2:integer
i,j:integer
begin
t1 = millisecs
tc=1
for j = 1 to 100
for i = 1 to 100000
inc(tc)
next
next
t2 = millisecs
MessageBox('time='+(t2-t1)+' tc='+tc)
t1 = millisecs
tc = 1
asm
@mov ecx,[!tc]
@mov ebx,100
.loop0
@mov eax,100000
.loop1
@inc ecx
@dec eax
@jnz loop1
@dec ebx
@jnz loop0
@mov [!tc],ecx
endasm
t2 = millisecs
MessageBox('time='+(t2-t1)+' tc='+tc)
end
notice the prefix on the opcode, personally I don't mind it (and will help with syntax highlighting, I think), but as a coder, any views ?
It's something I would probably stick on the list to remove, but it would be way off at the mo (next gen of the compiler, when I re-write the parser),
this would be a quick hack to get assembly into the language, in a reasonable way.
-
It makes it stand out a little bit better if anything.
The main reason for it being there is speed, so for me it wouldn't really make a lot of difference to have to use @ in front of the keywords, so it's cool.
-
Got this working...
Still not as fast as you want, rate limiting factor is the fullscreen move from the image buffer to display, I'm guessing freebasic is writing direct.
Still hunting tho ;)
Currently at 4-6 ms per raster.
(all for today, will pick it up at the weekend).
// RASTER EFFECT BY SHOCKWAVE.
// ---------------------------
// FEBRUARY 2007.
// LAME I KNOW, BUT FROM LITTLE ACORNS ETC....!!!! 11
//----------------------------------------------------------------------------------------------------------------------------------
PROGRAM USES PURE2D, KEYSET
//----------------------------------------------------------------------------------------------------------------------------------
CONST XRES = 640
CONST YRES = 480
VAR
GADD : REAL =0
GADD2: REAL =0
GADD3: REAL =0
v,r,j:integer
//----------------------------------------------------------------------------------------------------------------------------------
PROCEDURE INITIALISE()
BEGIN
OPENSCREEN( XRES , YRES)
END
//----------------------------------------------------------------------------------------------------------------------------------
//----------------------------------------------------------------------------------------------------------------------------------
// MAIN PROGRAM
//----------------------------------------------------------------------------------------------------------------------------------
VAR
Y : INTEGER
RD,GR,BL : REAL
t1,t2,d:real
BEGIN
INITIALISE()
WHILE NOT KEYDOWN (VK_ESCAPE)
GADD=GADD+1
GADD2=GADD2+2
GADD3=GADD3+3
d = millisecs -t1
t1=millisecs
FOR Y=0 TO YRES-1
RD = 125+((SIN(Y+GADD3)*50)+(COS(Y+GADD2)*50)-(SIN(Y+GADD)*24))
GR = 125+((SIN(Y+GADD2)*50)+(COS(Y+GADD)*50)+(SIN(Y+GADD3)*24))
BL = 125+((SIN(Y+GADD)*50)-(COS(Y+GADD3)*50)-(SIN(Y+GADD2)*24))
r = ToRGBA(rd,gr,bl)
v = ImagePointer + (y*xres*4)
j=xres
asm
@mov eax,[!r]
@mov ecx,[!j]
@mov edi,[!v]
@rep stosd
endasm
//LINE (0,Y,XRES,Y,TORGBA(RD,GR,BL,255))
NEXT
FLIP
WEND
MessageBox(d)
END
-
Nice work though :) Thanks!
Would it be possible to write direct to the screen in the future?
-
I'll certainly look at that as a possibility
-
If you could do that, it would make a lot of really neat stuff possible. Masochists like me would then be free to write their own fast drawing routines :)
Probably it would make code easier to port into Cobra from FB too.
-
You may be interested, that I've managed to crowbar basic assembler support into the patch I've just uploaded.
Not everything (obviously) but certainly a start.
-
Quality stuff, and thank you very much for being a developer that listens to it's userbase :)
Have some good Karma!
-
Totally agree with Shockwave. :cheers: