Integer VS Fpu
category: general [glöplog]
true
You are all missing the point. Opti is still working on qbasic and there fp/int does make a difference. *Even* on a 3GHz cpu.
It's like having to choose between a 3-speed and a 5-speed bicycle gear for his brand new Peugeot 206.
It's like having to choose between a 3-speed and a 5-speed bicycle gear for his brand new Peugeot 206.
altho not FPU related, but i'd like to note that HDR textures rock :)
someone should bitchslap some sense into optimus
I'm actually using the ALU to do float calculations and the FPU for integer maths (without conversion, of course. Only pussies use FILD or FIST[P]).
I agree with Shifter.
and i agree with ile.
Quote:
Zbs,. go on make your blobs with FPU when I can do them shitty fast with additive sprites
There are a few ways to Rome but plain additive sprites certainly is not among them.
Let's run this freak over with a truck!
It's pretty ok if you want to do it particle style, still those don't really count as "blobs", since in common terminology, "blobs" are usually referred to MC-triangulated iso-surfaces methinx.
On the other hand, why not take a look at the DX9.0a SDK to find out a nice 2.0 shader implementation of 2D blobs? :D
On the other hand, why not take a look at the DX9.0a SDK to find out a nice 2.0 shader implementation of 2D blobs? :D
He probably meant the 2D ones, for which there also are alternatives to MC of course, plain additive sprites not being one of them ;)
there are no alternatives to MC.
>Let's run this freak over with a truck!
This sounds like the sequel of Optisturvat..
This sounds like the sequel of Optisturvat..
APIs suxx.
Everything is sooo shite
I tried DDraw
I will try some PTC, perhaps it won't need 123 lines for doing stuff..
All I want is commands:
OpenWindow ()
Screen 800,600,32b
PutPixel (400,300),RGB(255,255,255)
TABs suxx
; suxx
OOP suxx
I am going back to Basic(s) :P
Everything is sooo shite
I tried DDraw
I will try some PTC, perhaps it won't need 123 lines for doing stuff..
All I want is commands:
OpenWindow ()
Screen 800,600,32b
PutPixel (400,300),RGB(255,255,255)
TABs suxx
; suxx
OOP suxx
I am going back to Basic(s) :P
TinyPTC rulez!!! I just went to the site to download it, watched some example test programm, it's fuckin easy with just 3 commands or something. Wow!
..like BASIC!!! =)
tinyptc would be nice but stuff like having a #define for windowed mode... sheesh :)
OOP sucks! BASIC rules!
OMG SAGACITY NOT YOU TOO????
I think I've been brainwashed by the 1 or 2 messages Optimus has posted on pouet in the past few years.
As Optimus said, I did some raytracing with integers and that... but it is all pure shit. It looked to be a little bit faster in a PII. But nowadays, programming 3d stuff with integers is a crazyness :). Anyway, I continue doing soft rendering and integer coding... it is just because I'm oldschool, and I don't know other way to code, but, I really know it is wasting time. Not using fpu and acceleration is a waste of computer power also. But, you know, oldschools love to waste time :)
when there are two parallel processors, one should concider to code like that...
Gargaj: why #define? you can ask your command-line or the usual question box api function...
Optimus: Beware of Floating-point. It is evil. If you code a synth someday, you could do it with floating-point, like many do, but you would have to deal with *denormalization*. It is what happens, when you multiply a small number by a small number and small number and a few times more, than you have a number so small, that floating-point cannot represent it in a normalized form. And working with these numbers is really, really fucking slow. So you would have to examine the exponent at some point, and zero out the number if it happens to be very small. Integer or fixed-point would do that for you automatically. So make your choice wisely.
There is an easy way to code in fixed-point: write a C++ class which would impersonate a fixed-point number and overload operators on it. Then you can use it like ... well, like magic! Some operations would be redundant, but they might either not be significant performance-wise, or the optimizer eliminates them in obvious cases. If you need more performance at some certain point, you can later rewrite some more complex operations per hand - but even then at least you have a working prototype and can ensure your algorithms are correct without too much effort.
Optimus: Beware of Floating-point. It is evil. If you code a synth someday, you could do it with floating-point, like many do, but you would have to deal with *denormalization*. It is what happens, when you multiply a small number by a small number and small number and a few times more, than you have a number so small, that floating-point cannot represent it in a normalized form. And working with these numbers is really, really fucking slow. So you would have to examine the exponent at some point, and zero out the number if it happens to be very small. Integer or fixed-point would do that for you automatically. So make your choice wisely.
There is an easy way to code in fixed-point: write a C++ class which would impersonate a fixed-point number and overload operators on it. Then you can use it like ... well, like magic! Some operations would be redundant, but they might either not be significant performance-wise, or the optimizer eliminates them in obvious cases. If you need more performance at some certain point, you can later rewrite some more complex operations per hand - but even then at least you have a working prototype and can ensure your algorithms are correct without too much effort.
eye: <sarcasm>no shit????? i thought my dialogboxes were ok as well. :(</sarcasm>
my point was that _TinyPTC_ has it as a compile flag.
my point was that _TinyPTC_ has it as a compile flag.
eye: Um yeah, denormalization is a much worse problem than, say, integers wrapping around...