| API's and Other Abstraction | page 1 2
|
|---|
|
|---|
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
05 Nov 2011 04:45
| We're not gonna have a system that will do 200 frames a second for the simple reason I don't see anyone having a monitor that can display 200 frames a second.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
05 Nov 2011 06:58
| Simple question could the API be used to make the system independent of the underlaying hardware?
| |
Claudio Wieland
Germany
| | (Natami Team)
Posts 703
05 Nov 2011 09:58
| Thomas Richter wrote:
|
Marcel Verdaasdonk wrote:
|
real time done in hardware, there is no such thing as real time in digital computers since there is always some latency question is it acceptable?
|
Guess what - the latency between your eyes and your consciousness is a lot larger. Or to put it differently, reality as you observe it is a nice fake by your brain, you're necessarely behind by many milliseconds. So don't be so harsh to computers, please.
[..]
|
That kind of latency is actually irrelevant for the daily life because what we experience appears to us like a contiguous stream of images, sounds etc . What we *do* perceive, though, are "holes" in that contiguous stream. So I'd rather like to discern between good and bad "realtime" ;-) . Putting the available silicon in the FPGA to use (which won't go away just because somebody decides to ignore it, and worse: the customer has already paid for it..) will lead to a better "realtime" experience than without. I hope you see my point.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
26 Feb 2012 21:09
| Since a bird told me we're getting a FPU too. How about steering this topic into another part of API's
OpenGL.
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
26 Feb 2012 22:14
| I think the Tami core is to be fixed-point and based on OpenGL-ES for that reason. Since a number of other SoC's use OpenGL-ES such as the one used in the Raspberry Pi, I think that shouldn't be much of a problem. There are libraries ported to the OpenPandora that have used OpenGL-ES as well, including a few macro-libraries to convert some code written in OpenGL to run on OpenGL-ES. The only hard part is that some implementations of OpenGL-ES use floating-point instead of fixed-point. We'll have to see how that goes. IMO, floating point as implemented by the IEEE standards should not be used in realtime code due to all the complexities of the standard. (Read that as: Floating point is a waste of silicon.) Also remember, Tami is a texture-mapping core and some geometry may have to be implemented in the CPU and FPU as well.
| |
Matt Hey
USA
| |
Posts 727
27 Feb 2012 00:23
| @Samuel D Crow
Floating Point is better at representing the large range of numbers used in 3D projections. I have seen integer values wrap around from calculations or numbers out of range, ruining the scene. Better integer saturation support and/or new carry/overflow sticky flags could improve the situation but it's not a worry with FP. FP could even save space if a 16bit 1/2 IEEE format was used (and the FPU supported reading and writing 1/2 IEEE). I think some of the complexities of the IEEE standard could be skipped in Tami (but NOT the FPU). FP support would probably be slightly slower. I have seen dual hardware registers that allow either FP or fixed point. I think OpenGL could and would be more easily adopted and supported by existing Amiga programs and ports. OpenGL-ES would probably be easier to implement and faster but isn't as useful until the Natami Phone arrives.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
27 Feb 2012 05:57
| I was trying to find what needed some more thought. OpenGL is easier in usage but requires more development effort.
I was looking for what is still required for the Natami to use OpenGL.
| |
|
Do you have ideas and feature wishes? Post them here and discuss your ideas.