Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Paul, odd 3D slow down issue

Author
Message
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Jan 2018 17:35 Edited at: 13th Jan 2018 17:36
Link
Paul (or anyone), I wonder if you can help please?

Ok, so this is going to take a little setting up, but here goes. I've been converting my 2D game to 3D, but the frame rate is really low - barely 45 fps, where it should be in the hundreds potentially. I;ve cut out all other code, and none of it made a difference, so I've employed the AppGameKit debugging commands. Some thiongs to note:

My machine is an 8 core AMD, with an 8gb GeForce GTX 1080, 16GB systme ram. The system is not slow (45fps in GTA V maxed out in 4k....so my simple graphics should be dstroyed).

So, here's some core things about the code:
SyncRate is set to (0,0) - there's no limit here.
A range of timings is used but the basics are that the time to render is measured as GetUpdateTime()+GetDrawingSetupTime()+GetDrawingTime() (this is on screen as "AGK render time"). This is backed up by getting the timer value before calling Sync, then again right after - they are roughly the same (this is on screen as "Render time"). Ib both cases, it says the render took less than 10% of a frame time, which at 60 fps is 0.0166666666666667 (1.0/60). Given this, the theoretical frame rate is about 500 FPS plus....but the code is slugging out at 45-50 fps. I will stress at this point, no other code is running in the background, and making it full screen does not impact it.

What I noticed is that the physics take 0.06 seconds on average (GetPhysicsTime()+GetPhysicsSolveTime())...but I do not use physics ANYWHERE in the game. In fact, I call delete3dphysicsworld before it starts to make sure. So what is this?

The frame update is done using the following code:


This should maintain a smooth set frame rate - I can set this to any value, however it is being limited by the system.

I then turn the 3D system off again and go back to the 2D game.....oddly this reports the maximum FPS as 70fps using the exact same code. Is this version there are no 3D objects beyond simple spheres, so no animation, no skeletons, no bones. The odd thing here is that the physics update time is still at 0.0522...why is that?

So a couple of key issues:
* what's the physics in the background that are measured and why are they taking up so much time? Is this impacting the 3d system?
*am I missing something obvious that is restricting the 3d frame rate - why is it topping out at 45 fps when it should be able to render at 400+ easily?
* are the limited 2D sprites slowing it down for some reason?

I would appreciate your feedback - the graphics are really very simple at this point, there shouldn;t be this severe level of slow down.

Video below tries to show.

Also, there is a problem with the internal shadows - they don't seem to clip with objects - I have an object casting a shadow on the floor, which goes right through the wall (a cube made internally in AppGameKit, protrudes below the floor) and onto the floor on the other side. Is this normal?

Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Jan 2018 17:57
Link
This second video moves the walls and roofs, so we can see that having every single object and person on screen seems to show little to no rendering slow down.

Back to top
Profile PM
Rick Nasher
7
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 14th Jan 2018 10:12 Edited at: 14th Jan 2018 10:29
Link
I can't really comment on the numbers(it's beyond me), but what I can tell you that I've noticed a slowdown when many (combined) 3d objects are moved at once.

In the 2nd vid where the walls are gone so I can see you are having a great deal of animated characters at the same time. If they are procedurally generated then I assume you are moving/rotating their bodyparts?
The walls are removed easily. Are they one individual object or many separate ones? Are you perhaps using FixObjectToObject?
I noticed a severe slowdown when building many procedural objects and using above command.

If so you are probably better off generating the static parts of the building such as walls in a 3d editor and load as 1 object.

I'm relatively new to AppGameKit, but from experiences in other languages I know that to keep up the FPS in situations like this , people mostly only animate/show/render/move the objects that are actually currently in view, so you could set up a system to do this. For instance display only those in a certain range, or use GetObjectInScreen() to animate/move only the ones on screen. Also you can reduce the camera range if it's an indoor game, which it appears to be and when outdoors do the same and to hide this play with fog settings.

Oh. and shadows I've noticed too. I had a building and all shadows were working great, except at the elevator which had thin walls.
It would be handy to have a command to adjust the length of the shadows. A way around this perhaps could be thicker walls and/or use SetObjectReceiveShadow() to have thin objects not receiving shadows(as I did that for the elevator walls)?

Hope this helps.
Back to top
Profile PM Email Website
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 13:04
Link
Hi Rick.

Thanks for the comments, some interesting things to think about. Unfortunately the game is set up so that people can completely design the inside of the ship themselves, so pre-rendered walls isn;t an option, but there is no fix object to object at work here. I also looked at culling objects outwith the camera (this is Fullstrum culling I think?) but it was far slower to check the objects rather than just leave it to AGK.

For me it's more about understanding what's happening in the background - from everything I tested I am thinking that possibly either the benchmark commands aren't taking everything into account (recent updates maybe?), or that there is something bottlenecking AppGameKit that we just don't have the facility to benchmark.

Essentially I get the timer value, call a regular Sync(), then take the timer and the time passed is so much smaller than the frame rate it makes no sense. The physics timings are also really bizarre when I have zero physics objects set up.

For the shaddows, the walls are cubes 50x50 in terms of width and depth - so surely that's not too thin? I;d be really interested to see if anyone else has this issue - I suspect I may HAVE to merge the walls togther witht he floor into a single object in memory for this to work as I expect, so I'll experiment with that. Turning them off or down improves it slightly, but the numbers are still lagging far below what should be possible.

Turning animation off, or even adding zero crew members, barely impacts the frame rate. That's what's so confusing - the graphics card is barely being taxed - even the windows performance monitor shows barely 9% usage when running the game. I want to adapt and develop it for VR using the DLC, but with this lag there's simply no way it would run at speeds that would be enjoyable to play.
Back to top
Profile PM
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 14th Jan 2018 17:29
Link
Quote: "What I noticed is that the physics take 0.06 seconds on average (GetPhysicsTime()+GetPhysicsSolveTime())...but I do not use physics ANYWHERE in the game. In fact, I call delete3dphysicsworld before it starts to make sure. So what is this?"


Those Physics time commands are for the 2D physics only. Calling delete3dphysicsworld does absolutely nothing unless you have
called Create3DPhysicsWorld(). 3D Physics is only turned on by calling Create3DPhysicsWorld() and then stepping it in the loop.
Apparently Paul leaves the 2D physics tuned on all the time.
The coffee is lovely dark and deep,and I have code to write before I sleep.
Back to top
Profile PM Email Website
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 18:18
Link
That's really interesting to know. I'd be curious to see what the 2d physics covers, as I don't use those at all either. Given the hit on 3d, and the fact I do my collision checking manually anyway I'd love to see it be able to be turned off so I could really dedicate to the 3d.
Back to top
Profile PM
Bengismo
7
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 14th Jan 2018 18:51 Edited at: 21st Jan 2018 08:49
Link
EDITED
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 19:45
Link
Hi Bengisimo.

Yes, that's what I've done. If I load a sole object I can get 4000+ fps, so I'm now wondering if having any 2d at all might be part of an issue.

I've disabled all ai and everything else, but the fact of the matter is the benchmarking commands show it takes a fraction of the sync time to do all the calculating and rendering. So either something isn't counted, or there might be a bottle neck.

I'll keep looking in the mean time, but there's little to no other code running (you'll note the newest video shows no crew moving) beyond input control.
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 19:47
Link
Or maybe the internal sorting and image management.....but that's surely counted within the benchmarking commands?
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 20:51 Edited at: 14th Jan 2018 20:53
Link
Ok, so I had a look from a different perspective. Here the game is literally turned off - the set up is done, then it just goes into a Do:Loop that does NOTHING in the middle except get the benchmarks and draw the text. In option 1 it has the sprites, in option 2 I use DeleteAllSprites() directly before the loop to get the measure with no sprites. The default camera is looking right at a wall, so there are ZERO visible 3D objects beyond about 5 cubes made internally.

The outcome is as follows:

With sprites:
Game runs at 56.7 FPS
Render took 0.001663 milliseconds (of 0.01667 target) - which is 10.0% of the time for a frame
Physics time was 0.000099
Physics solve time was 0.092323
Max possible Frame rate (based on drawing time) is 540 (ish)

With zero sprites:
Game runs at 54.7 FPS (??? - it did hover up to around 57 occasionally)
Render took 0.001579 milliseconds (of 0.01667 target) - which is 9.5% of the time for a frame
Physics time was 0.000092
Physics solve time was 0.086207
Max possible Frame rate (based on drawing time) is 721 (ish)

Note, the micro numbers vary and calc either side of the Sync().

But what this shows....WITHOUT ANY OTHER CODE RUNNING AT ALL...is that the Physics solve time seems really high, even with no sprites and no use what so ever of the 2D physics. If this is threaded it may not impact the screen refresh, but whatever the cause this should draw at hundreds of frames per second, but can't even hit 60fps.

Attachments

Login to view attachments
Back to top
Profile PM
Bengismo
7
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 14th Jan 2018 20:57 Edited at: 21st Jan 2018 08:49
Link
EDITEDv
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 20:57
Link
As a side note, I left the code running and the physics solve time kept creeping up above 0.1......so unless the language that AppGameKit uses is totally varying from one benchmark measure to another that means that:

drawing takes 0.001663 miliseconds
Physics can take up to 0.1 milliseconds

That's an enormous variation when there is no physics...or 2D items....at all on screen???
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Jan 2018 20:59
Link
Nope, all turned off - or should be. Here the looop code exactly as is:

Back to top
Profile PM
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 15th Jan 2018 03:16
Link

so how many objects individual make up the world and do they have separate textures ?

if the world is made up of lots individual objects, then I suspect you'll need to look into building an occlusion solution. Given that this world seems to be a maze of interconnected rooms you could build zones for each room and either pre-compute or dynamically compute what volumes the camera can see from it's current position. One way would be make what walls in the zone are open and link volumes that share this wall. Dynamic objects are attached to each zone. I suspect the number of draw calls is affecting the performance. You could merge all the static geometry into room sized meshes or the entire world entire world, but that might choke low end GPU's....


PlayBASIC To HTML5/WEB - Convert PlayBASIC To Machine Code
Back to top
Profile PM Website
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 15th Jan 2018 19:42
Link
At the moment it comes in at 1 almost for each sprite, so about 2000. The are all textured, but currently there is only one texture that is on every one.
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Jan 2018 01:00
Link
Can you make a simple project close to what you actually have that we can test? I think then we may see something causing the issue.

For example, I noticed in your first code snippet in top post you have this...


Which seems to be a loop inside your loop waiting for a certain time which would effectively limit the fps it seems?

Not sure if it helps at all but I did test the code you provided above (where you said here is the loop code exactly) and this is what I get on my laptop...

TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 16th Jan 2018 01:21
Link
Yeah, the looptimer is because in the actual code it does this:

After sync, get the timer
Add 0.016667 to the timer (for 60 fps)
Deduct the total time the last frame took to render

So when the loop cycles if repeats system checks and ai calls etc until the next frame needs to be rendered to maintain the target frame rate. Not perfect, but it allows me to effectively thread ai across frames.

The second demo doesn't have this, and ai etc was disabled in the first test.

I'm away until Friday, but will dig more into the number of items etc then, and upload some form of demo.

I do note that you get AppGameKit itself says the render took 0.000603 seconds.....and 1400 fps. This seems far more reasonable. I wonder if somewhere my system is forcing a frame limit I can't see? I've also now come across a possible issue with rendering to an image.....it seems to erase the 3d world if you screen record using Nvidia shadow play in full screen. In the last video on fb I show the player using the captain's chair. Works fine windowed, but full screen the entire 3d world.vanishes.

Possible Nvidia driver issue?? That needs more testing though.
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 16th Jan 2018 01:25
Link
That said, you have no assets loaded.....So maybe some form of sorting or queuing action is taking place that the benchmark commands don't pick up?

Friday I'll try that code in an empty project, see what I get but on second thoughts i Don't think it's my system though.....I have an object editor that runs at 1100+ fps.

Bass anyone tried large numbers of sprites/objects before? 1500 plus?
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Jan 2018 01:39 Edited at: 16th Jan 2018 01:48
Link
"I wonder if somewhere my system is forcing a frame limit I can't see?"

I think that is very possible and worth checking into. On my laptop I am pretty sure I can set my video card to wait for the vsync for example and not allow apps / games to override it. It could be something like that is happening on your machine perhaps.

I have a 2D framework I worked on last year that renders a lot of sprites for all of the tiles (multiple layers) as well as the characters and items, etc.

For example the back parallax layer has the sky and the far mountain. Then we have the next mountain layer. Then another. Then the layer with the trees. Then the foreground layer which is ground and the platforms that can be traveled on. All of the collectibles, enemies, player, etc. Not sure if it is over 1,500 but might be. Didn't really pay much attention to it because I haven't run into any performance issues.




I'm not sure if it represents the same kind of thing you are doing though. I used no 3D... just 2D. And just made the world in the Tiled map editor with numerous layers (layers not only for what we see but layers for enemies, layers for items, layers for doors, warp points and so forth). Load it all into arrays and render from that.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 16th Jan 2018 07:50
Link
Could you overlay the timing code into your loop and see if you start to see a variation from actual to expected frame rates?

My game started as 2d with lots of paralax layers too, and that was ok. Not the fastest render, but it was ok.
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Jan 2018 15:29
Link
Sure I can do that tonight (after work) although I expect that will definitely slow it down. In my experience printing to the screen has always been very inefficient in every language and every computer I have used.

It makes me wonder if maybe that is the actual bottleneck you are seeing? Have you tried letting the calculations take place but not displayed each frame and then have them dump out say once per 10 seconds or so followed by a sleep 5000? I expect that would improve performance a fair amount.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 16th Jan 2018 15:53
Link
I've done it in a real world environment where debugging was turned off and it never made a difference. Worth a shot though I guess.
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Jan 2018 17:03 Edited at: 17th Jan 2018 03:45
Link
I was just thinking.... I usually put some thought into designing for performance just out of habit. And I think what I actually did was not process all tiles on each layer in realtime. It seemed silly to do so and I did not need truly unlimited scrolling areas.

Instead IIRC I set up images representing 10.x screens wide X 14.x screens tall. With the idea being this is the maximum size of a scrolling area some 140+ screens. However, the entire game world consists of a large number of these areas (of different sizes... perhaps one area might even be a single screen, some horizontal only, others vertical only and others both horizontal and vertically scrolling).

So although I use the tile map data for all collision checking the actual tiles themselves are prerendered onto these larger images (one for each graphics layer). Which means for 5 layers of parallax there are only 5 large sprites and not the hundreds / thousands of sprites needed if I went with individual tiles.

I forgot about that until just now thinking about it.

I did make an unlimited scrolling parallax tile map engine with sprites for each individual tile in the past before doing this though. Seems like i released the source in a forum post here as well. No doubt long since buried but perhaps that would be a better test case.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Jan 2018 23:58 Edited at: 17th Jan 2018 05:43
Link
I dug out my old FUSTME (Fast Unlimited Size Tile Map Engine... whew what a name lol) project.

Attached to this post. It only sets up 396 sprites but maybe it will be useful in some way for your profiling.

Well I guess just let us know if there is any test we can do. When you get your demo code ready I will give it a try.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)

Attachments

Login to view attachments
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 17th Jan 2018 20:17
Link
Awesome, thanks for that.

It's amazing, but in my 2d game I did exactly what you did, and used memblocks to build the floor as one single, massive sprite.

I'm back home Friday, so as soon as I'm back I will give it a bash.

I had a random thought.....I had issues before and copied everything into a brand new project and the issues went away. Worth a shot, you never know. I hope to start playing with VR soon, but at these speeds I'm not convinced it will work.
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Jan 2018 00:42 Edited at: 18th Jan 2018 00:42
Link
Sounds good. Hope a new project sorts it out.

Note: I did just notice that I forgot to actually upload the source for that tile map engine and demo in my post above so I just edited it to do that.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 20th Jan 2018 20:17
Link
Ok, so I broke this down even further and it's just muddied the water even more. I now did away with Sync and replaced it with:


Now what I see is that the majority of the frame is the shadows, so I switched them off and got about an extra 30fps. However, that now means that my machine, which has a 1080GTX 8GB card at it's heart, is not still only running my simple graphics at 70fps. However, if we look at the info captured in the attached we see that:
The historic timer says that the render takes an average of 0.002329 seconds per frame - remember at 60fps we should have 0.016667 per frame - so that's still 7.16% of the time we SHOULD have. So lets look at the breakdown:
Update(0) - 0.001266
Render2DBack() - 0.000092
RenderShadowMap() - 0.000214
Render3D() - 0.009247
Render2DFront() 0.000931
Swap() - 0.000122
ClearDepthBuffer() - 0.000000 (this occasionally said 0.000004 which I have gone with)

Now, these are interspersed with timer() calls, however if we add them up: 0.001266+0.000092+0.000214+0.009247+0.000931+0.000122+0.000004 = 0.011876.

So what we immediately see is that the AppGameKit reported render time is actually far, far lower than the "sum of the parts" so to speak....in actual fact, it's only 20% of the time. Which works mathematically as the FPS is reported as a 5th of what should be possible.

So, is there a problem witht he benchmarking/internal timing commands?

I think the basic slowdown comes from the following two things:
Texture size (look at the rendered pixels - 13,955,136 against a resolution of 2560x1600 (4,096,000 pixels) and a virtual resolution of 1920x1080 (2,0733,600 pixels).
AGK DESPERATELY needs a shader built in along the lines of the one Dark Basic got that clips out objects which are hidden from the drawing engine - if I recall that added about 600-700% to that rendering speed, and since it is based on the same out of date DX technology (I believe) that is likely a hugely restricting factor.

Has anyone gotten such a culling shader working in AppGameKit?

Attachments

Login to view attachments
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 20th Jan 2018 20:41
Link
Ok, so I've now shrunk all the images to a fraction of their original size and the impact on the frame rate was about 1 FPS at best - in fact oddly it got slower in places, pressumably where the draw calls had to "make up" more data when smoothing the much smaller textures scaled over a much larger screen area.

However, the pixels rendered seems unaffected.

What I have noticed is that walking outside the ship and turning around and looking at the wall....where only 3 primative cubes are present, shows 549,000 polygons rendered. If I turn around, this drops to 12 (the ground).

So.......essentially AppGameKit just drwas every single object in front of the camera with no consideration of culling due to other objects hiding them, and the benchmarking commands don't *seem* to capture everything that correctly....or at least the help files don't report the time units accurately?
Back to top
Profile PM
Bengismo
7
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 20th Jan 2018 22:06 Edited at: 21st Jan 2018 08:48
Link
EDITED
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 21st Jan 2018 00:02
Link
Bengismo.

Actually, why would Windows NOT be taken into account for the frame time? And why would an antivirus impact frame rendering time that wouldn't be picked up?

I would thank you for the response, but you're rude and aggressive - so actually I'd appreciate YOU not assuming what I do or do not undrstand, and NOT replying again.
Back to top
Profile PM
Bengismo
7
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 21st Jan 2018 00:03 Edited at: 21st Jan 2018 08:50
Link
Good luck
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 21st Jan 2018 01:03 Edited at: 21st Jan 2018 01:29
Link
@Santman I was just doing some testing for a project in another thread to see the performance benefits of changing certain options and I think you are right those drawing stats are not correct maybe.

For example, setting all objects invisible (i.e. no longer could see them on the screen) the GetPixelsDrawn() returned the same values as before when they were all visible.
And when everything was visible being drawn GetDrawingTIme() returned 0.006 and when everything was invisible not being drawn GetDrawingTime() returned 0.01

I would read that as it is saying regardless of whether the pixels are actually being drawn or not they are being counted by the GetPixelsDrawn function.
And I would read that as GetDrawingTime is saying it is less (faster) to draw thousands of objects than it is to draw nothing.

Actually though looking closer at GetDrawingTime docs say that is the time waiting for frame end or flip or whatever (I don't have docs in front of me atm but remembered seeing something like that) so that actually does make sense... the less there is to draw the more time need to wait for whatever... the more there is to draw the less time need to wait.

Anyway just wanted to share that. I'd say don't get hung up on the values returned by these things.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
IronManhood
9
Years of Service
User Offline
Joined: 6th Feb 2015
Location: US
Posted: 21st Jan 2018 05:32
Link
Try SetSyncRate( 0, 1 ) my friend.
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 21st Jan 2018 16:00 Edited at: 21st Jan 2018 16:02
Link
I'm not focussing on the figures now, the individual stage breakdowns are showing the frame rate as being pretty much where it should be.....so now the huge variance is gone I'm happy. I need to optimise some models, but I also found a vertex shader that automates drawing a bounding box and then calculating which bounding boxes oclude others, so gives a fairly automatic exclusion cull for solid objects. Won't work for items or anything you need to see through, but should work fine for the single blocked walls and doors. IF I can get it working (shaders are not my thing at all!).

I've confirmed, thanks to the kind generosity of TGC, that the windows mixed reality headset does indeed seem to work Ok, so if I can up the speed a little more I'm going to start playing with that. My immediate goal is to allow the player, in VR, to order the ship to a planet then play with letting them teleport to the surface. I already have a basic planet procedure up and running, but it needs work.

IRONMANHOOD....turned off already. Though I noticed what appears to be another bug. If you use Setvsync(1) then run your code, it uses sync. If you totally delete the code, compile and run again......sync stays on. Actually, it stays on until you add the code line back in and use Setvsync(0) specifically. Or it does for me. This doesn't appear to be the problem with my code Though, I turn it off at the start of each loop.

Not sure why that setting would be persistent across multiple runs.
Back to top
Profile PM
MikeHart
AGK Bronze Backer
21
Years of Service
User Offline
Joined: 9th Jun 2003
Location:
Posted: 23rd Jan 2018 09:09
Link
Sandman wrote: "since it is based on the same out of date DX technology (I believe) that is likely a hugely restricting factor."


AGK is OpenGL/OpenGL ES based.
Running Windows 7 Home, 64 bit, 8 GB ram, Athlon II X2 255, ATI Radeon HD 4200. Using AGK2 Tier 1.
Back to top
Profile PM
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 31st Jan 2018 11:01
Link
Of course it is.....DOH
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-24 02:40:11
Your offset time is: 2024-11-24 02:40:11