MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001541Zandronum[All Projects] Bugpublic2013-10-14 05:392017-01-31 07:25
ReporterStrikerMan780 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformPCOSWindows 7OS VersionUltimate x64
Product Version1.2 
Target VersionFixed in Version 
Summary0001541: Models not in view/obscured by map geometry are still rendered, causing massive FPS annihilation.
DescriptionAs it is, model rendering in Zandronum is incredibly inefficient, with ports like Doomsday and games like Quake 3 handling twice as many models and polys on-screen without ruining FPS... But, there's one thing here that I consider a major "bug":

Models that are completely obscured by a wall are still rendered, and if there's lots of models (ie. Trees), they will completely bomb your framerate, wasting processing power doing nothing. (If you cannot see it, why render it?)
Steps To ReproduceLoad treetest.pk3 (Attached), and you'll find that the framerate is terrible, despite not being able to see any of the trees beyond the wall. This is a common occurrence in some WADs, such as in TNT/Evilution, and UDMX where some maps have massive fields of trees lying around as a backdrop.
Additional Information
TagsNo tags attached.
Relationships
Attached Files? treetest.pk3 (1,074,700) 2013-10-14 05:39
https://zandronum.com/tracker/file_download.php?file_id=1084&type=bug
Issue History
Date ModifiedUsernameFieldChange
2013-10-14 05:39StrikerMan780New Issue
2013-10-14 05:39StrikerMan780File Added: treetest.pk3
2013-10-14 05:43StrikerMan780Note Added: 0007405
2013-10-14 06:53Dark-AssassinNote Added: 0007406
2013-10-14 07:22StrikerMan780Note Added: 0007407
2013-10-14 07:22StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4137
2013-10-14 07:23StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4138
2013-10-14 07:24StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4139
2013-10-14 07:30StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4140
2013-10-14 07:30StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4141
2013-10-14 07:31StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4142
2013-10-19 22:18StrikerMan780Note Added: 0007439
2013-10-19 22:21StrikerMan780Note Edited: 0007439bug_revision_view_page.php?bugnote_id=7439#r4158
2013-10-19 22:22StrikerMan780Note Edited: 0007439bug_revision_view_page.php?bugnote_id=7439#r4159
2013-11-29 02:52StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4235
2013-11-29 02:53StrikerMan780Note Edited: 0007407bug_revision_view_page.php?bugnote_id=7407#r4236
2013-12-31 09:23StrikerMan780Note Edited: 0007439bug_revision_view_page.php?bugnote_id=7439#r4307
2013-12-31 09:34Torr SamahoNote Added: 0007783
2013-12-31 09:35Torr SamahoNote Edited: 0007783
2013-12-31 09:36Torr SamahoNote Edited: 0007783bug_revision_view_page.php?bugnote_id=7783#r4310
2013-12-31 09:36Torr SamahoNote Revision Dropped: 7783: 0004308
2013-12-31 09:37Torr SamahoNote Revision Dropped: 7783: 0004309
2014-06-15 14:53WatermelonNote Added: 0009401
2014-06-15 14:53WatermelonStatusnew => confirmed
2014-07-28 16:48MonsterovichNote Added: 0010064
2014-07-28 16:49MonsterovichNote Edited: 0010064bug_revision_view_page.php?bugnote_id=10064#r5414
2014-07-28 16:55MonsterovichNote Edited: 0010064bug_revision_view_page.php?bugnote_id=10064#r5415
2014-07-28 16:58MonsterovichNote Edited: 0010064bug_revision_view_page.php?bugnote_id=10064#r5416
2014-07-29 01:09Edward-sanNote Added: 0010066
2014-07-29 07:53MonsterovichNote Added: 0010073
2014-07-29 07:58MonsterovichNote Edited: 0010073bug_revision_view_page.php?bugnote_id=10073#r5422
2014-07-29 07:58MonsterovichNote Edited: 0010073bug_revision_view_page.php?bugnote_id=10073#r5423
2014-07-29 08:04MonsterovichNote Edited: 0010073bug_revision_view_page.php?bugnote_id=10073#r5424
2014-07-29 09:10Edward-sanNote Added: 0010075
2014-07-29 10:56MonsterovichNote Added: 0010079
2014-07-29 11:03MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5432
2014-07-29 11:06MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5433
2014-07-29 11:08MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5434
2014-07-29 11:08MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5435
2014-07-29 11:10MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5436
2014-07-29 11:13MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5437
2014-07-29 11:14MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5438
2014-07-29 11:19MonsterovichNote Edited: 0010079bug_revision_view_page.php?bugnote_id=10079#r5439
2014-07-29 11:35StrikerMan780Note Added: 0010081
2014-07-29 11:36StrikerMan780Note Edited: 0010081bug_revision_view_page.php?bugnote_id=10081#r5441
2014-07-29 11:46MonsterovichNote Added: 0010082
2014-07-29 11:46MonsterovichNote Edited: 0010082bug_revision_view_page.php?bugnote_id=10082#r5443
2014-07-29 11:46MonsterovichNote Edited: 0010082bug_revision_view_page.php?bugnote_id=10082#r5444
2014-07-29 11:47MonsterovichNote Edited: 0010082bug_revision_view_page.php?bugnote_id=10082#r5445
2014-07-29 13:41Edward-sanNote Added: 0010085
2014-07-29 13:41Edward-sanNote Edited: 0010085bug_revision_view_page.php?bugnote_id=10085#r5447
2014-07-29 15:35MonsterovichNote Added: 0010086
2014-07-29 15:38MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5449
2014-07-29 15:39MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5450
2014-07-29 15:45MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5451
2014-07-29 15:48MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5452
2014-07-29 15:48MonsterovichNote Edited: 0010073bug_revision_view_page.php?bugnote_id=10073#r5453
2014-07-29 15:51MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5454
2014-07-29 15:52MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5459
2014-07-29 16:04MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5460
2014-07-29 16:05MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5461
2014-07-29 16:06MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5462
2014-07-29 16:25MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5463
2014-07-29 16:26MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5464
2014-07-29 16:27MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5465
2014-07-29 16:30MonsterovichNote Edited: 0010086bug_revision_view_page.php?bugnote_id=10086#r5466
2014-07-29 19:05Edward-sanNote Added: 0010089
2014-07-29 20:05MonsterovichNote Added: 0010090
2014-07-29 20:08MonsterovichNote Edited: 0010090bug_revision_view_page.php?bugnote_id=10090#r5468
2014-07-29 20:09MonsterovichNote Edited: 0010090bug_revision_view_page.php?bugnote_id=10090#r5469
2014-07-29 20:56MonsterovichNote Edited: 0010090bug_revision_view_page.php?bugnote_id=10090#r5470
2014-07-30 03:39Blzut3Note Added: 0010096
2014-07-30 05:34StrikerMan780Note Added: 0010097
2014-07-30 05:35StrikerMan780Note Edited: 0010097bug_revision_view_page.php?bugnote_id=10097#r5475
2014-08-02 22:13FastclickNote Added: 0010112
2014-08-03 16:04Edward-sanNote Added: 0010116
2014-08-03 19:07StrikerMan780Note Added: 0010118
2015-03-15 23:52StrikerMan780Note Added: 0011830
2016-01-21 14:33StrikerMan780Note Added: 0014144
2016-01-21 14:34StrikerMan780Note Edited: 0014144bug_revision_view_page.php?bugnote_id=14144#r8494
2016-01-21 14:35StrikerMan780Note Edited: 0014144bug_revision_view_page.php?bugnote_id=14144#r8495
2016-01-21 14:35StrikerMan780Note Edited: 0014144bug_revision_view_page.php?bugnote_id=14144#r8496
2016-01-25 17:50ibm5155Note Added: 0014201
2016-01-25 17:54StrikerMan780Note Added: 0014203
2016-01-25 17:55StrikerMan780Note Edited: 0014203bug_revision_view_page.php?bugnote_id=14203#r8570
2016-01-25 18:23KorshunNote Added: 0014204
2016-01-25 20:10StrikerMan780Note Added: 0014205
2016-01-25 20:10StrikerMan780Note Edited: 0014203bug_revision_view_page.php?bugnote_id=14203#r8571
2016-01-26 07:07Torr SamahoNote Added: 0014206
2016-01-26 07:07Torr SamahoNote Edited: 0014206bug_revision_view_page.php?bugnote_id=14206#r8573
2016-01-26 07:08Torr SamahoNote Revision Dropped: 14206: 0008572
2016-01-26 15:36StrikerMan780Note Added: 0014209
2016-01-26 15:37StrikerMan780Note Edited: 0014209bug_revision_view_page.php?bugnote_id=14209#r8583
2016-01-26 15:38StrikerMan780Note Edited: 0014209bug_revision_view_page.php?bugnote_id=14209#r8584
2016-01-26 15:38StrikerMan780Note Edited: 0014209bug_revision_view_page.php?bugnote_id=14209#r8585
2016-01-26 19:17Torr SamahoNote Added: 0014210
2016-01-26 20:48StrikerMan780Note Added: 0014211
2016-01-27 18:14Torr SamahoNote Added: 0014212
2016-01-27 18:24StrikerMan780Note Added: 0014213
2016-01-27 18:25StrikerMan780Note Edited: 0014213bug_revision_view_page.php?bugnote_id=14213#r8587
2016-11-24 10:54Edward-sanNote Added: 0016313
2016-11-25 00:14RevilutionNote Added: 0016315
2016-11-25 14:15StrikerMan780Note Added: 0016317
2016-11-25 17:26RevilutionNote Added: 0016318
2017-01-31 07:24StrikerMan780Note Added: 0016740
2017-01-31 07:25StrikerMan780Note Edited: 0016740bug_revision_view_page.php?bugnote_id=16740#r10096

Notes
(0007405)
StrikerMan780   
2013-10-14 05:43   
I'll make another test to see if completely sealed walls produce the same result.
(0007406)
Dark-Assassin   
2013-10-14 06:53   
I can confirm this.
Also, I believe that some Sprites are also rendered through walls, but only to a limit. This is more an engine limitation AFAIK.

Also, from what I heard from SoulPriestess (Eruranna) a while ago is that each Vertex rendered in GZD/ST/Zandro are all dynamic instead of static, which also counts towards massive FPS loss.
(0007407)
StrikerMan780   
2013-10-14 07:22   
(edited on: 2013-11-29 02:53)
For models, all vertexes *should* be considered static unless it's an animated model, but they are not, by what you are saying... correct?

(I can understand it being dynamic for Doom's geometry, due to how things work there with moving sectors and all.)

On an unrelated note... Doom really needs a better Visibility system in general, that functions on both Axis instead of just one. (And some frustum culling, ie. Don't render anything that is outside the camera's FOV.)
(0007439)
StrikerMan780   
2013-10-19 22:18   
(edited on: 2013-12-31 09:23)
BTW, the framerate annihilation might be part due to the fact that the MD2/MD3 code does vertex and geometry transformation/processing EVERY FRAME in software(CPU), rather than as needed in hardware(GPU) from what I can remember.

IIRC, this was a huge waste of performance, and one of the biggest bottlenecks in IDTech 2 and IDTech 3-Based games, which was something that certain source ports fixed, such as ETXreaL.

EDIT: Apparently Zandro/GZDoom's model code doesn't use vertex arrays, and instead just uses GL_BEGIN? Would that be part of why performance is so bad?
(0007783)
Torr Samaho   
2013-12-31 09:34   
(edited on: 2013-12-31 09:36)
Vertex arrays could help. Does anybody have time to experiment with vertex arrays in the model code? I'm not sure how well the vertex arrays will work with the interpolation and the movement of actors though. The level geometry the current vertex array code is used for is mostly static.
(0009401)
Watermelon   
2014-06-15 14:53   
Definitely can confirm this, it ruined a mod idea I had
(0010064)
Monsterovich   
2014-07-28 16:48   
(edited on: 2014-07-28 16:58)
>Vertex arrays could help. Does anybody have time to experiment with vertex arrays in the model code? I'm not sure how well the vertex arrays will work with the interpolation and the movement of actors though. The level geometry the current vertex array code is used for is mostly static.

Hm, I made VBO for models sometime, but indices were messed and idk why, it must work anyway..

'http://s29.postimg.org/axun5xnp3/Screenshot_Doom_20140713_170309.png [^]'

Common vertex buffers would help in this situation. That means the same models will be joined in one array. This is more effective than drawing each model from each array and better than glBegin/glEnd shit.

The main problem is an animation, because I don't know what I should do with this.
Shader animation ftw. :P
(0010066)
Edward-san   
2014-07-29 01:09   
Can you reproduce on gzdoom glew branch graf is working on? This is the thread, but you should find the latest experimental build in one of the last pages.
(0010073)
Monsterovich   
2014-07-29 07:53   
(edited on: 2014-07-29 15:48)
>Can you reproduce on gzdoom glew branch graf is working on? This is the thread, but you should find the latest experimental build in one of the last pages.

No, graf broke opengl 2.* support, new gzdoom branch won't run at all for me.


Unsupported OpenGL version. *Ha-ha-ha!*
At least GL 3.0 is required to run GZDoom. *Graf'd!*


I think, he seriously needs a doctor.
(0010075)
Edward-san   
2014-07-29 09:10   
Since, I suppose, you're not a programmer, I'm not surprised about this reaction.

Which graphics do you have?
(0010079)
Monsterovich   
2014-07-29 10:56   
(edited on: 2014-07-29 11:19)

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6200/AGP/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 304.116
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler


Some games (for example: q3-q2 engine based games) have 5x more polygons on ultra large maps. They work faster than GZDoom crap and don't require OpenGL 3.0.


* here graf will blame sector engine *
(0010081)
StrikerMan780   
2014-07-29 11:35   
(edited on: 2014-07-29 11:36)
The old ZDoomGL based on ZDoom 1.22 runs just about as fast on my Voodoo2 card with Creative MiniGL, as GZDoom runs on some modern systems that I've used.
(0010082)
Monsterovich   
2014-07-29 11:46   
(edited on: 2014-07-29 11:47)
>The old ZDoomGL based on ZDoom 1.22 runs just about as fast on my Voodoo2 card with Creative MiniGL, as GZDoom runs on some modern systems that I've used.

Try GLBoom, that will show you how GZDoom performance sucks on high-poly maps.
(0010085)
Edward-san   
2014-07-29 13:41   
Quote
GeForce 6200

Come on, you can find a decent and cheap video cards which have at least OpenGL 3.x support.


Quote
Some games (for example: q3-q2 engine based games) have 5x more polygons on ultra large maps.


That's because these engines have a different rendering algorithm. Doom is not OpenGL friendly at all, because the calculations are done by the CPU for the 90%. You don't know what are you talking about.

Quote
Try GLBoom, that will show you how GZDoom performance sucks on high-poly maps.


prBoom does not need to be compatible with zdoom maps, so its rendering algorithm is naturally faster than zdoom, as zdoom maps do more complicated things which require more conditions to check for the actors in the game.


Just give up. You can't improve the performances without using advanced features from recent gl.
(0010086)
Monsterovich   
2014-07-29 15:35   
(edited on: 2014-07-29 16:30)
>>Come on, you can find a decent and cheap video cards which have at least OpenGL 3.x support.

What?
OpenGL 3.0 release date is: August 11, 2008. That means graf broke support of ALL videocards before 2008.

>Doom is not OpenGL friendly at all, because the calculations are done by the CPU for the 90%. You don't know what are you talking about.

calculations != optimal rendering

>prBoom does not need to be compatible with zdoom maps, so its rendering algorithm is naturally faster than zdoom, as zdoom maps do more complicated things which require more conditions to check for the actors in the game.

Prboom & ZDoom? We are talking about OpenGL, because software is very old thing from 90s. (but sometimes it could work faster than gzdoom, ha-ha)

Actually, ZDoom maps is not a reason. Let's check performance on vanilia maps then:
'http://www.doomworld.com/idgames/?file=levels/doom2/Ports/0-9/5l1c.zip [^]'
For example: this map has no zdoom features, but my fps in GZDoom is 10-5.
In GLBoom this map works VERY fast: 52-70 fps. GLBoom renderer is 5-10x faster!! and it doesn't need OpenGL 3.0 to play. My conclusion - GZDoom's renderer is crap.
GLBoom is a good example how OpenGL port must work. I guess, if GLBoom had ZDoom features like 3d floors, slopes.., they would work faster, because of good optimization. Finally, everyone is lazy to fork ZDoom and 45% of people have better videocards, where GZDoom is not so laggy, but this will not help to 3d models. :D
(0010089)
Edward-san   
2014-07-29 19:05   
Quote
OpenGL 3.0 release date is: August 11, 2008. That means graf broke support of ALL videocards before 2008.

Sorry, but it doesn't sound too much time (6 years is a lot)...

Quote
calculations != optimal rendering

Since GPUs can't do math (except for GPGPU cards), CPUs have to do it, hence the CPU bottleneck.

Quote
Prboom & ZDoom? We are talking about OpenGL, because software is very old thing from 90s. (but sometimes it could work faster than gzdoom, ha-ha)
It was proved by profiling that the major responsible of the difference between glboom and gzdoom is on the zdoom side (really, the renderer is innocent), as proved here.

Quote
In GLBoom this map works VERY fast: 52-70 fps. GLBoom renderer is 5-10x faster!! and it doesn't need OpenGL 3.0 to play. My conclusion - GZDoom's renderer is crap.
GLBoom is a good example how OpenGL port must work. I guess, if GLBoom had ZDoom features like 3d floors, slopes.., they would work faster, because of good optimization. Finally, everyone is lazy to fork ZDoom and 45% of people have better videocards, where GZDoom is not so laggy, but this will not help to 3d models. :D

Then prove it. Fork GLBoom and add the ZDoom features. Then let us know if it's really faster than GZDoom. I'm serious. :D
(0010090)
Monsterovich   
2014-07-29 20:05   
(edited on: 2014-07-29 20:56)
>Then prove it. Fork GLBoom and add the ZDoom features. Then let us know if it's really faster than GZDoom. I'm serious. :D

Thanks, no, add OpenGL to ZDoom is more easier than add ZDoom to GLBoom.

Performance comparison on high poly map:
'http://s23.postimg.org/njzd69gez/opengl_nazi_glboom_gzdoom_perfor_mance.png [^]'
(0010096)
Blzut3   
2014-07-30 03:39   
I do not see how this debate is contributing towards solving the problem, so I will declare it ended here. Monsterovich, if you think it's possible to do better, then write a better renderer. Graf's ability or inability to optimize the renderer is not dependent on people's ability to complain about it.
(0010097)
StrikerMan780   
2014-07-30 05:34   
(edited on: 2014-07-30 05:35)
The model code of the OpenGL renderer isn't optimized well, as was the original topic of this report.

However, if you're talking OpenGL overall, it's mainly the ZDoom engine itself that really needs optimization. However, for that some stuff may need to be rewritten. (Me, personally, would like to see a Vis/Nodes system that works in all 3 Dimensions for geometry culling. It would make large maps a lot more viable when you have big mountains dividing the places up.)
(0010112)
Fastclick   
2014-08-02 22:13   
The easiest solution to this problem can be a "render distance" and "3d model render distance" (Like in Doomsday) option.
Am i right ?
(0010116)
Edward-san   
2014-08-03 16:04   
Still, what about the latest builds of gzdoom on drdteam site? Still the same problem?
(0010118)
StrikerMan780   
2014-08-03 19:07   
Same problem.
(0011830)
StrikerMan780   
2015-03-15 23:52   
Looking back on the discussion, the fact that Doom is mostly CPU-bound shouldn't be the primary cause for the Model code specifically to cause such a major performance hit. That is something that can be improved, regardless. The main issue as I can tell, is that the model code does software transformations, plus all models are considered dynamic.

I was thinking, could a STATIC flag for MODELDEF be implemented, for models that a modder knows will never move or animate in any way, shape or form, and thus drop any unnecessary calculations in the process? Perhaps apply some form of caching/array/buffer for them since they won't be animating?
(0014144)
StrikerMan780   
2016-01-21 14:33   
(edited on: 2016-01-21 14:35)
Now that I'm more experienced with OpenGL, having had to write a renderer of my own for Hellbender... I think the best approach here for models labeled as being static, is to store each model into Indexed Elements that can be re-used, translated/rotated when being drawn to the screen as needed for all instances of the model in view. This way the model data is held in GPU memory, there's fewer draw calls, and less CPU->GPU overhead.

Also, any immediate mode (glBegin/End) stuff, if still there, desperately needs to be removed. Vertex Arrays for the win.
(0014201)
ibm5155   
2016-01-25 17:50   
But what about making the game to use more than one thread? it could speed up things alot since the problem is zandronum is only using a single core.
I can say Graf is trying to make the game faster, but, as said, doom isnt gl friendly, and trying to emulate such software thing in gl is a pain in the ass.
And that's why the opengl req from the new gzdoom, because wi gl 4.0 there're better ways to send a bi amount data to the gpu, at the cost of removing potato gpu support
(0014203)
StrikerMan780   
2016-01-25 17:54   
(edited on: 2016-01-25 20:10)
Doom isn't well-suited to multi-threading. It'd require a huge fundamental rewrite of the game (like Mocha Doom). The only thing that is multi-threaded currently is the sound system, which can be safely separate from the game-sim. Rendering however, cannot.

That's irrelevant to this however.
(0014204)
Korshun   
2016-01-25 18:23   
This issue is actually two different issues contributing to the bad performance:

1) models behind high walls are rendered even if they can't be seen

2) models are rendered using glBegin/glVertex/glEnd

The second issue is particularly egregious. Vertex-animated models should have all their frames uploaded into a vertex buffer and should be animated using a simple vertex shader (OpenGL 2.0 is enough for this) that interpolates between two vertex positions based on time.

Instead, they are rendered the most inefficient way possible: by re-uploading the whole model every time it's rendered, EVERY FRAME, and even if THE SAME MODEL is rendered multiple times, EVEN IF IT HAS NO ANIMATION. It's no wonder that rendering a bunch of identical non-animated models causes such an fps drop.

Also, this all has nothing to do with multithreading and how fast the rest of zandronum is.
(0014205)
StrikerMan780   
2016-01-25 20:10   
Yeah. It's basically what I've tried explaining in previous posts.
(0014206)
Torr Samaho   
2016-01-26 07:07   
Striker, then please go ahead and rewrite the code with vertex arrays. If you already had to write your own renderer, you should have sufficient OpenGL experience to do this. I'll happily add improvements to the model rendering code and likely Graf will as well.
(0014209)
StrikerMan780   
2016-01-26 15:36   
(edited on: 2016-01-26 15:38)
It might take a while since I am still busy with Hellbender. (Just so you know I'm not talking out of my ass:'http://puu.sh/kzCpM/334d5c6a9e.png [^]''http://puu.sh/lgS1z/45bfe0d590.png [^]' )

All I need to know is which source file to look at for model drawing. Also, MODELDEF parsing. Any up-to-date compiling instructions too, since last time I checked the Wiki, they were out of date.
(0014210)
Torr Samaho   
2016-01-26 19:17   
Quote from StrikerMan780

It might take a while since I am still busy with Hellbender. (Just so you know I'm not talking out of my ass:'http://puu.sh/kzCpM/334d5c6a9e.png [^]''http://puu.sh/lgS1z/45bfe0d590.png [^]' )

Nice!

Quote from StrikerMan780

All I need to know is which source file to look at for model drawing. Also, MODELDEF parsing.

That should all be in src/gl/models/gl_models.cpp.
Quote from StrikerMan780

Any up-to-date compiling instructions too, since last time I checked the Wiki, they were out of date.

The VC++ 2005 guide on the Wiki should still be fine. If you have problems compiling, just let me know.
(0014211)
StrikerMan780   
2016-01-26 20:48   
I use Visual Studio 2015 CE. I can't run VS2005.
(0014212)
Torr Samaho   
2016-01-27 18:14   
Then you need to use cmake instead of the VC++ 2005 project files. There is a WIP cmake guide:'http://wiki.zandronum.com/User:Csnxs/VSGuide_Sandbox [^]'
(0014213)
StrikerMan780   
2016-01-27 18:24   
(edited on: 2016-01-27 18:25)
Thanks. When I have some free time I'll take a crack at it. No guarantees since I'm still pretty new, and Hellbender was a good starting point for me since it's code is pretty straightforward C (I hate C++ with a passion), but I'll do my best.
(0016313)
Edward-san   
2016-11-24 10:54   
Do you mind trying latest gzdoom builds? There should be a huge improvement due to non-moving actors doing uselessly expensive calculations.

Of course this won't mean we'll port these improvements to zandronum 3.0.
(0016315)
Revilution   
2016-11-25 00:14   
I can say that the lastest GZDoom builds have more stable fps for extensive maps with abusive use of OpenGL features.

Here's a screenshot comparison of the most open-field area i did for my mod:
'http://i.imgur.com/Gf52d6W.jpg [^]'

In GZDoom the FPS only drops below 30 when there's too many projectiles flying in this area while in Zandronum it is always below 30FPS even if there are no monsters.
(0016317)
StrikerMan780   
2016-11-25 14:15   
Do those areas heavily abuse models as well? Or just other OpenGL features?

I will say framerate is better than it was, even with models, but I can't test it thoroughly at the moment since I'm short on time (going on vacation for a while, starting soon).
(0016318)
Revilution   
2016-11-25 17:26   
It does, items, weapons in HUD and pickup, monsters and trees are all 3D models, they can't be noticed so much because i resized the image but they are there, this corridor have lots of items and that garden behind the red forcefield have foliage decoration, all of them being 3D models, just the monster count that isn't all that insane due to the map's complexity on this area already getting most of the performance.
(0016740)
StrikerMan780   
2017-01-31 07:24   
(edited on: 2017-01-31 07:25)
The difference in the latest GZDoom is massive. treetest.pk3 doesn't have a single dip in framerate whatsoever. (1ms difference between models being drawn or not) I see by looking at the source they went ahead and already gotten rid of glBegin/glEnd crap, and are using Vertex Arrays, so what I had planned to do is already taken care of.