TTD graphics lib Progress

[TinDragon]

Well I got an reasonable oval drawing routine in, not really sure why I need ovals and there not filled at the moment but I am sure I will find some use for them. Been thinking about getting a poly draw in next but I wouldn't mind getting some form of text writer in so I can get some debug info going.

[Shockwave]

You'll need a text command and a font. I posted one, you'll find it if you go through Stonemonkeys graphicslib post. You can use that if you want to.
http://dbfinteractive.com/index.php?topic=128.0

[TinDragon]

Thanks Shockwave, I will have a go at putting the font code in for debug purposes and hopefully I am getting good fps. Would still like to code my own text system that can use bitmapfonts but that can wait till I get to it 

[Shockwave]

I also posted a conversion of the Courier font (8 point) you can find it in the graphics forum, no small letters yet but I'll have that done soon.

[TinDragon]

Hehe, these fps are crazy if there right there a good deal faster than blitz at double the res.
Pixel pushing has never been so much fun 

[TinDragon]

Well the TTD lib has progressed in leaps and bounds thanks to Zawran jumping in and coding some cool functions for it. One wierd thing we discovered was the fact FB uses radians and not degrees, had a few wierd results due to that one. I Like using #define for inline functions, blitz needs compiler directives like that, dont know why it doesnt. All in all FB seems a reasonable setup for a free language only one effect, that tunnel with the greentiles, seems to be slower than the blitz version I did, not sure why but thats the only thing slower so far. Now to put what we have to some use   

[Shockwave]

Convert your sine data into degrees;

Degree = radian * pi /180

[TinDragon]

Yep already have that in our code to go both ways, but on a different bit of code, to do with 3d rotation I am getting a completely different result to what I expected and the code is 100% the same as the blitz version apart from me doing the degree/radian bit's in the code. Mind it was late at night and maybe I have got a variable as an integer that needs to be a float will take another look when I am back in the ide.

[zawran]

I wasn't too keen on even trying out FB since I am perfectly happy using Bmax, but Jon convinced me to at least give it one tryout and see what I thought. The one thing about it that I have taken interest in is that using TinyPTC you will have to do everything yourself rendering wise. So plot, lines, sprites, whatever will have to be manually coded. That was interesting, so I dug a little bit deeper into it and is helping Jon out with his graphics library and its getting to the point where it could really be used for something, so I am looking forward to see what we can do with it in terms of demos/intros. Its going to be retro looking which is another reason I like it, because thats what I like in demos. I don't care much for most new 3D demos, they just doesn't give me the same feeling as watching retro stuff. Its probably because I was there throughout the C64 and Amiga era and coding demos in ASM on them that I like it so much.

[Stonemonkey]

I've ended up with:

Code: [Select]

const deg_rad_conv=3.14159265/180.0
#define cs(a) cos(a*deg_rad_conv)
#define sn(a) sin(a*deg_rad_conv)

at the start of my stuff so you just need
cs(degrees) or sn(degrees)

or you could make a lookup table.

[Shockwave]

That's a good idea Stonemonkey.
I think it's very good practive to do your divisions as #define statements. Should gain bags of time, especially if you are rotating a lot of stuff.

[TinDragon]

I did pretty much the same in my lib

Code: [Select]

#define _sin(angle) sin(angle* 3.1415926535897932 / 180)
#define _cos(angle) cos(angle* 3.1415926535897932 / 180)But I am having wierd problems with 3d rotations and I have no idea why