Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

3d Performance On Vapire With Openglpage  1 2 

Vladimir Repcak

Posts 353
01 Aug 2020 19:22


Markus B wrote:

  If you need a game's idea, take a look at something like Indianapolis 500 (https://www.youtube.com/watch?v=KmCFPrLNZZM) oder the famous Formula One Grand Prix.
 
  I'd love to see such game in SAGA (940x560 or 1280x720).

Oh, I don't need a game idea. I have more technical game designs in my notepad than I could finish in dozen lifetimes :)

I should really just lock the engine feature set and create final art assets. But, all this discovery about 640x480 and higher resolutions is making it very hard to stop experimenting...

However, a formula game is in my Top 3 (after the first game)...


Vladimir Repcak

Posts 353
01 Aug 2020 19:34


Andy Hearn wrote:

  Cow3D is 5813Tris /2914 points at ~>1fps
  running this in a nearly full-screen window on a 800x600x16bit screen. dropping down to 640x480x15bit doesn't seem to improve any performance. 8bit just displays a blank window. again, colouring-vs-texturing doesn't change much.

That is weird that it wouldn't render in 256 colors. Maybe it requires materials explicitly defined ? Perhaps it is explained in the docs.
~3,000 vertices and ~6,000 triangles, in C is going to be slow.
At such low framerate it is hard to discern any performance difference.

Andy Hearn wrote:

 
  but this punishment in performance is the price for a nearly complete (as i understand it) implementation of an early form of  OpenGL - running entirely in 68k software... thats worth it in my eyes, however inefficient. but not something base something beyond an "it works" technical demo. I know nothing about how any of this goes together - but i imagine boiling it down to it's base constituents would lead to some big gains. maybe some AMMX magic here or there? ;)

I'm not saying the current OpenGL implementation is inefficient. OpenGL is a beast, in terms of approaches, features and tricks.

I'm just saying that if all that OpenGL code is in C, then there is simply no way it can be remotely fast.

Even if Vampire was 1,000 MHz, you would still get ~10 fps instead of 1 fps. That's still ridiculous.

Forget AMMX, any ASM code would result in a huge improvement. But, that's a gargantuan effort.

I would guesstimate that if somebody devoted ~1,000 hours (6 months full-time) on porting most critical stuff to ASM, you could get a useable OpenGL API.


Vladimir Repcak

Posts 353
01 Aug 2020 19:42


I would have to see the ScenGraph/StateMachine benchmarks of the inner loop of our OpenGL implementation, but in general, the shortest route to performance gains would be:

1. Port 3D transform code to ASM
2. Port triangle rasterization code to ASM
3. Disable Z-Buffer and force coder to sort polys manually (like I do)

I would have to see the actual source code to get an idea how much work that is. I think I saw the github link somewhere around these forums.


Samuel Crow

Posts 395
02 Aug 2020 04:20


Kas1e has done the grunt work of porting Irrlicht to AmigaOS 4.1FE using the OpenGL-ES2 layer of Warp3D Nova.  Going the extra step of porting the software renderer to the Vampire might be a possibility because it uses 15 bit high color rendering pipeline (plus one bit of transparency mask) by default.

EXTERNAL LINK


Vladimir Repcak

Posts 353
02 Aug 2020 19:07


irrLicht is nice, but as with any 3rd party 3D engine, unless you are creating a game that *exactly* fits the underlying pipeline, you will inevitably hit unfixable issues later down the road and will have to cut down some major features. Which really sucks (as the alternative is to remove the offending component, which is tied to dozen other components and you end up rewriting more than half of code).

Back in the day, around 2000, when there were several alternatives like Ogre, IrrLicht (and few others), I've seen this happen too many times.

The time you burn on debugging other people's engines is way disproportionate to the time it would take you to write a simple wrapper layer above OpenGL/DirectX that would handle Texture Loading, Frustum Culling and material handling.

Not to mention you learn so much more when you have to implement certain design aspects between engine components in C++.


Vladimir Repcak

Posts 353
03 Aug 2020 06:50


I browsed around this forum and found some links for tinyGL's implementation of triangle rasterization:

C:
EXTERNAL LINK  EXTERNAL LINK 
ASM:
EXTERNAL LINK  EXTERNAL LINK  EXTERNAL LINK 

These should answer any questions about the final performance :)

Theoretically, it should be possible to port the triangle rasterizer fn during a ~weekend.

But since it's doing so many checks per scanline and/or pixel (Z-Buffer, blending, texturing, other OpenGL features), it's not going to be miraculously faster.

If we want performance, then all those checks above need to happen per object level (not even per triangle!). Meaning, we need separate functions for all common combinations of the OpenGL features.
That's easily around 16 functions (at least)...

Just one dispatch/switch case per Draw call (), choosing appropriate raster fn based on currently enabled features.

Then it could, indeed, be significantly faster. I seriously doubt, even if it was coded full-time, that all those could be done in a month...

From that standpoint, it's really starting to make more and more sense to just write an OpenGL-style wrapper around my engine. Currently, there wouldn't be any texturing or Z-Buffer (could be added in 2 weeks of work), but it would be lightning fast and work in all resolutions...


Ozzy Boshi

Posts 9
03 Aug 2020 09:14


Thank you for all of your inputs, in the meantime I reworked the code to see if i could fit the whole rodonea concept inside a stock a600, the final result is this

EXTERNAL LINK 
I also presented the demo at the flashparty in argentina ( my first ever amiga challenge ).

Since I targeted a stock amiga I had to strip all real time calculations that were possible on a vampire but soon I realized that this would be too much data for 1mb chip ram.
I spent a lot of time optimizing the algorithm, at first i was using 4 bytes to represent a point in a cartesian plane. Too much for my amiga.
Then I changed method and used points deltas and I was able to compress each point in 1 byte, applying huffman compression i saved some more space but i wasted computing time to decompress.

What did I get from this experience?
When programming for stock Amigas most of the time you have to precalculate and your demo is just a "precalculated data player" of your routines, this is not fun as real time calculations.

I must add that the rodonea demo I presented is 100% hand made code, I mean I dont use any pre-made libraries to do stuff.
For example, printing a pixel is just a matter of calculating the right bitplane byte and setting the nth bit to 1.
Simulating the rotations along xyz axe is made with a dot product routine against a 32 bit fixed point matrix.
Same thing for the projection , I built an ortho projection matrix and applied the same multiplication routine.
Thank god I found the dot product routine on github, at least I could copy and paste it (and rework a bit) to make it run on amiga.

In my opinion the average developer needs tools to avoid all this time wasting, solving problems already solved is useful only for learning.
That is the reason why I approached openGl on Amiga, If I had some sort of engine where you put inside your music and opengl code, it would be a lot of fun and new great demos would start to appear on vampire.

Just for example, if you follow the pouet demoscene there is a group committed to morpohos that uses "encore engine" to make very good demos. I bet they spent half of the time I spent coding a single screen demo like "rodonea"because they have this engine. I know morphos+ppc is has nothing to do with vampires but it would be cool to have a demotool easy to understand and well documented for 3d stuff with opengl.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4886
03 Aug 2020 10:51


Yes you are right:
Coding on Amiga or C64 was always about clever tricks and smart ways of doing things.

The whole point in all cool games and demos was about finding the best "trick" to make stuff possible which were not able to do with "naiv" straight forward coding.


Gunnar von Boehn
(Apollo Team Member)
Posts 4886
03 Aug 2020 11:40


Ozzy boshi wrote:

That is the reason why I approached openGl on Amiga, If I had some sort of engine where you put inside your music and opengl code, it would be a lot of fun and new great demos would start to appear on vampire.

I doubt OpenGl is the way.
OpenGL is an interface for talking to a GFX accelerator card.
This means OpenGL defined "calls" which are then processed by millions of transistor on the GFX card.

A Software renderer in OpenGL is something like an "Emulation"
and the unoptimized naiv compile of such code for Amiga - is the certainly  the most slowest way you can find to do 3D.

This is similar to running Microsoft Word in emulated Windows in PC-Task to do some text editing on Amiga - this works but is certainly one of the most slowest ways.


Thellier Alain

Posts 118
03 Aug 2020 12:09


@Gunnar
  Absolutely right
  Making a fast triangles rasterizer with texture is not difficult
  But if you want to emulate fully OpenGL or Warp3D then you must manage all the cases : texture Y/N Blended Y/N zbuffer etc...
  So become slow
  All the GL problem bas been discussed several times here
  EXTERNAL LINK  See the link to cow3d I gave here
 
  Wazp3D dont have chunky 8 bits rendering like waRp3D : unused
 
  Textured/untextured speed: texture need u v computation, untextured need r g b a so 4 channels to compute
 


Ozzy Boshi

Posts 9
03 Aug 2020 13:28


I agree with Gunnar but I want to say that the goal of the projecto was not to build a demo and win the flashparty.
I just wanted to find out if opengl "emulation" could be useful for simple projects and understand what can be done or not.
In order to do this I decided to use dotted rodoneas because:
- drawing a point should be not so heavy
- we dont have reflections and light to manage and the result could be pretty
- there is only one scene and one object on the screen
- i can tweak quickly the accuracy if i see the vampire struggling, with a minor change i can go from 360 points to 720 and so on...

So at the end what did I learn?
Opengl on amiga works quite well but performance is a serious issue even on a vampire card.
The same executable works way better on an apple g4 with morphos (probably because i have a radeon inside) but i am not targeting this platform.
I think I am doomed, I must try to write my own routines for matrix transformation. I wont get all the features but there is a good possibility I get something smooth even with my naive programming.

Gunnar von Boehn wrote:

Ozzy boshi wrote:

  That is the reason why I approached openGl on Amiga, If I had some sort of engine where you put inside your music and opengl code, it would be a lot of fun and new great demos would start to appear on vampire.
 

 
  I doubt OpenGl is the way.
  OpenGL is an interface for talking to a GFX accelerator card.
  This means OpenGL defined "calls" which are then processed by millions of transistor on the GFX card.
 
  A Software renderer in OpenGL is something like an "Emulation"
  and the unoptimized naiv compile of such code for Amiga - is the certainly  the most slowest way you can find to do 3D.
 
  This is similar to running Microsoft Word in emulated Windows in PC-Task to do some text editing on Amiga - this works but is certainly one of the most slowest ways.




Gunnar von Boehn
(Apollo Team Member)
Posts 4886
03 Aug 2020 13:39


Ozzy boshi wrote:

I think I am doomed, I must try to write my own routines for matrix transformation.

I would not call this doomed.

A few people wrote very good matrix transformations for Amiga/Vampire.
Also John and Andre from our team wrote very good ones.
Talk to them, they can certainly give you some fast code.



Vladimir Repcak

Posts 353
03 Aug 2020 22:23


Ozzy boshi wrote:

  EXTERNAL LINK 
  I also presented the demo at the flashparty in argentina ( my first ever amiga challenge ).
Cool. You have a first finished demo with music and on OCS! That's a great starting point!
 

Ozzy boshi wrote:

  Since I targeted a stock amiga I had to strip all real time calculations that were possible on a vampire but soon I realized that this would be too much data for 1mb chip ram.
  I spent a lot of time optimizing the algorithm, at first i was using 4 bytes to represent a point in a cartesian plane. Too much for my amiga.
  Then I changed method and used points deltas and I was able to compress each point in 1 byte, applying huffman compression i saved some more space but i wasted computing time to decompress.

Yep, the times when you could just brute-force your way through data and wow the audience are about 30 years in past at this point.

 
Ozzy boshi wrote:

  What did I get from this experience?
  When programming for stock Amigas most of the time you have to precalculate and your demo is just a "precalculated data player" of your routines, this is not fun as real time calculations.

Correct. Vast majority of cool demos are merely "players". The trick is to mask the precomputing part by mixing it into another effect - for example while the scroller is running, you are precomputing next effect, bit by bit, each frame, without slowing down currently run effect.

Or, if you are going for the AGA, then you can have a 40 MB file that already has all stuff precomputed, you just need to mask loading the data per effect in parallel with current effect running.

Ozzy boshi wrote:

  In my opinion the average developer needs tools to avoid all this time wasting, solving problems already solved is useful only for learning.

But the satisfaction you get when it's all just your own code makes it worthwhile :)

Ozzy boshi wrote:

  That is the reason why I approached openGl on Amiga, If I had some sort of engine where you put inside your music and opengl code, it would be a lot of fun and new great demos would start to appear on vampire.
 
  Just for example, if you follow the pouet demoscene there is a group committed to morpohos that uses "encore engine" to make very good demos. I bet they spent half of the time I spent coding a single screen demo like "rodonea"because they have this engine. I know morphos+ppc is has nothing to do with vampires but it would be cool to have a demotool easy to understand and well documented for 3d stuff with opengl.

I follow pouet, but not familiar with morphos. Can you post a link ?


Vladimir Repcak

Posts 353
03 Aug 2020 22:39


@Ozzy boshi : Since you already have a tested baseline demo code for OCS (with music and everything), how about we merge our brains and do some simple demo together ?
 
  There's a CRX event (online this year) on Aug-29 - about 3.5 weeks from now.
  Link:
  EXTERNAL LINK 
 
  Since it's not a full-blown demo-event, with all those groups that have been in the business for over quarter century, we could mash something simpler together, and not be ridiculed.
  Maybe something simple like Invitro ?
 
  I could spare some hours for this in parallel with working on my game.
 
  V4 as a target, yes ? Is that what you have at home ?
  Using my engine, I think we could target 640x480@32 bit and adjust camera speed to the resulting framerate (to keep it smooth)...

We could use my engine to import some nice car 3d mesh and keep it aligned with the CRX's neon theme - see the link for an example:
EXTERNAL LINK 
You could create some other scenes.


Ozzy Boshi

Posts 9
04 Aug 2020 08:29


I dont see what advantage gives us my little background on ocs.
Yes we can reuse some of my concept but I guess programming on a rtg screen would be another story if compared to ocs.
It would be great however to join forces, at least for me because it would be a great opportunity to learn something new, in these days I am preparing for a Cisco exam and it's very boring, all slides and nomenclature to store in my mind.
Even a single pixel displayed on my Amiga screen is far more exciting.
If you want to show me your engine I would be glad to use it (if I have the knoledge to do this, I will need your help at first).

My target is a little bit esotheric, it would be an rtg screen on a vampire v600 (maybe with apollo os running underneath).
I dont own a v4 and for now I dont have plans to get one (I am about to lose my job and I dont want to spend money unless is absolutely necessary) but I think that if it works on v600 should potentially work even in a v4.

I like your idea for the 3d car, actually I have other ideas to further develop the concept, but if you want we can talk about this privately.

I didnt know this crx event, it seems cool but the due date is too soon for me, I am a slow learner and I doubt I will get something for the end of August.

If you want we can talk more about this privately, I would be very happy to try to do something. You can find me on the apollo-team slack channel as Alessio Garzi or Ozzyboshi on skype.


Vladimir Repcak

Posts 353
04 Aug 2020 12:28



 
Ozzy boshi wrote:

  I dont see what advantage gives us my little background on ocs.
 

  That's mostly for future. Right now I don't want to mess with 7 MHz target and bitplanes, but later it might come in handy having a baseline code with audio and gfx.
 
 
 
Ozzy boshi wrote:

  My target is a little bit esotheric, it would be an rtg screen on a vampire v600 (maybe with apollo os running underneath).
  I dont own a v4 and for now I dont have plans to get one (I am about to lose my job and I dont want to spend money unless is absolutely necessary) but I think that if it works on v600 should potentially work even in a v4.
 

  v600 is fine. It still has 128 MB, I presume ? But you do have it at home, right ? Meaning you can test code right away ?
  It would also be interesting for me to have benchmarks from that target.
 
 
Ozzy boshi wrote:

  I like your idea for the 3d car, actually I have other ideas to further develop the concept, but if you want we can talk about this privately.
 
  I didnt know this crx event, it seems cool but the due date is too soon for me, I am a slow learner and I doubt I will get something for the end of August.
 

  You could certainly script some scenes with some 3D logos or animated abstract 3D line art (think - tunnel, but kinda wireframe).
  You would simply call functions like DrawLine3D (Vertex1,Vertex2,color), that doesn't require too much focus and is quite fun in itself. But, it can get tedious and requires a lot of experimenting.
Since we have 24 bit RTG framebuffer, we have zero limitations to the colors used - full range R.G.B color - 16.777.216

 
 
Ozzy boshi wrote:

  If you want we can talk more about this privately, I would be very happy to try to do something. You can find me on the apollo-team slack channel as Alessio Garzi or Ozzyboshi on skype.

  It's too distracting for me to code anything with a public IRC channel open :)
 
  Can you hit me up on my yahoo email (FullName@Yahoo.com) ?


Andy Hearn

Posts 328
04 Aug 2020 14:03


My A600 is coming back from re-capping courtesy of Amiga Passion, this week. would be happy to help test anything if needed


Vladimir Repcak

Posts 353
04 Aug 2020 17:17


The unfortunate feature of deadlines (Aug-29) is that they tend to pass regardless of whether you're ready or not :)

Should we accidentally manage to finish something :) by that fixed date, it'll be a public download, of course.

posts 38page  1 2