Zandronum Chat @ irc.zandronum.com
#zandronum
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Attached Files? file icon treetest.pk3 [^] (1,074,700 bytes) 2013-10-14 05:39

- Relationships

-  Notes
User avatar (0007405)
StrikerMan780 (reporter)
2013-10-14 05:43

I'll make another test to see if completely sealed walls produce the same result.
User avatar (0007406)
Dark-Assassin (administrator)
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.
User avatar (0007407)
StrikerMan780 (reporter)
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.)

User avatar (0007439)
StrikerMan780 (reporter)
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?

User avatar (0007783)
Torr Samaho (administrator)
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.

User avatar (0009401)
Watermelon (developer)
2014-06-15 14:53

Definitely can confirm this, it ruined a mod idea I had
User avatar (0010064)
Monsterovich (reporter)
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

User avatar (0010066)
Edward-san (developer)
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.
User avatar (0010073)
Monsterovich (reporter)
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.

User avatar (0010075)
Edward-san (developer)
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?
User avatar (0010079)
Monsterovich (reporter)
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 *

User avatar (0010081)
StrikerMan780 (reporter)
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.

User avatar (0010082)
Monsterovich (reporter)
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.

User avatar (0010085)
Edward-san (developer)
2014-07-29 13:41
edited on: 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.

User avatar (0010086)
Monsterovich (reporter)
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

User avatar (0010089)
Edward-san (developer)
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
User avatar (0010090)
Monsterovich (reporter)
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 [^]

User avatar (0010096)
Blzut3 (administrator)
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.
User avatar (0010097)
StrikerMan780 (reporter)
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.)

User avatar (0010112)
Fastclick (reporter)
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 ?
User avatar (0010116)
Edward-san (developer)
2014-08-03 16:04

Still, what about the latest builds of gzdoom on drdteam site? Still the same problem?
User avatar (0010118)
StrikerMan780 (reporter)
2014-08-03 19:07

Same problem.
User avatar (0011830)
StrikerMan780 (reporter)
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?
User avatar (0014144)
StrikerMan780 (reporter)
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.

User avatar (0014201)
ibm5155 (reporter)
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
User avatar (0014203)
StrikerMan780 (reporter)
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.

User avatar (0014204)
Korshun (reporter)
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.
User avatar (0014205)
StrikerMan780 (reporter)
2016-01-25 20:10

Yeah. It's basically what I've tried explaining in previous posts.
User avatar (0014206)
Torr Samaho (administrator)
2016-01-26 07:07
edited on: 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.

User avatar (0014209)
StrikerMan780 (reporter)
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.

User avatar (0014210)
Torr Samaho (administrator)
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.
User avatar (0014211)
StrikerMan780 (reporter)
2016-01-26 20:48

I use Visual Studio 2015 CE. I can't run VS2005.
User avatar (0014212)
Torr Samaho (administrator)
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 [^]
User avatar (0014213)
StrikerMan780 (reporter)
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.

User avatar (0016313)
Edward-san (developer)
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.
User avatar (0016315)
Revilution (reporter)
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.
User avatar (0016317)
StrikerMan780 (reporter)
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).
User avatar (0016318)
Revilution (reporter)
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.
User avatar (0016740)
StrikerMan780 (reporter)
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.


Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: Monsterovich Fastclick Korshun ZzZombo ibm5155 djskaarj JC Tenton MaxRideWizardLord JusticeSkulltag
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2013-10-14 05:39 StrikerMan780 New Issue
2013-10-14 05:39 StrikerMan780 File Added: treetest.pk3
2013-10-14 05:43 StrikerMan780 Note Added: 0007405
2013-10-14 06:53 Dark-Assassin Note Added: 0007406
2013-10-14 07:22 StrikerMan780 Note Added: 0007407
2013-10-14 07:22 StrikerMan780 Note Edited: 0007407 View Revisions
2013-10-14 07:23 StrikerMan780 Note Edited: 0007407 View Revisions
2013-10-14 07:24 StrikerMan780 Note Edited: 0007407 View Revisions
2013-10-14 07:30 StrikerMan780 Note Edited: 0007407 View Revisions
2013-10-14 07:30 StrikerMan780 Note Edited: 0007407 View Revisions
2013-10-14 07:31 StrikerMan780 Note Edited: 0007407 View Revisions
2013-10-19 22:18 StrikerMan780 Note Added: 0007439
2013-10-19 22:21 StrikerMan780 Note Edited: 0007439 View Revisions
2013-10-19 22:22 StrikerMan780 Note Edited: 0007439 View Revisions
2013-11-29 02:52 StrikerMan780 Note Edited: 0007407 View Revisions
2013-11-29 02:53 StrikerMan780 Note Edited: 0007407 View Revisions
2013-12-31 09:23 StrikerMan780 Note Edited: 0007439 View Revisions
2013-12-31 09:34 Torr Samaho Note Added: 0007783
2013-12-31 09:35 Torr Samaho Note Edited: 0007783
2013-12-31 09:36 Torr Samaho Note Edited: 0007783 View Revisions
2013-12-31 09:36 Torr Samaho Note Revision Dropped: 7783: 0004308
2013-12-31 09:37 Torr Samaho Note Revision Dropped: 7783: 0004309
2014-06-15 14:53 Watermelon Note Added: 0009401
2014-06-15 14:53 Watermelon Status new => confirmed
2014-07-28 16:48 Monsterovich Note Added: 0010064
2014-07-28 16:49 Monsterovich Note Edited: 0010064 View Revisions
2014-07-28 16:55 Monsterovich Note Edited: 0010064 View Revisions
2014-07-28 16:58 Monsterovich Note Edited: 0010064 View Revisions
2014-07-29 01:09 Edward-san Note Added: 0010066
2014-07-29 07:53 Monsterovich Note Added: 0010073
2014-07-29 07:58 Monsterovich Note Edited: 0010073 View Revisions
2014-07-29 07:58 Monsterovich Note Edited: 0010073 View Revisions
2014-07-29 08:04 Monsterovich Note Edited: 0010073 View Revisions
2014-07-29 09:10 Edward-san Note Added: 0010075
2014-07-29 10:56 Monsterovich Note Added: 0010079
2014-07-29 11:03 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:06 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:08 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:08 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:10 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:13 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:14 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:19 Monsterovich Note Edited: 0010079 View Revisions
2014-07-29 11:35 StrikerMan780 Note Added: 0010081
2014-07-29 11:36 StrikerMan780 Note Edited: 0010081 View Revisions
2014-07-29 11:46 Monsterovich Note Added: 0010082
2014-07-29 11:46 Monsterovich Note Edited: 0010082 View Revisions
2014-07-29 11:46 Monsterovich Note Edited: 0010082 View Revisions
2014-07-29 11:47 Monsterovich Note Edited: 0010082 View Revisions
2014-07-29 13:41 Edward-san Note Added: 0010085
2014-07-29 13:41 Edward-san Note Edited: 0010085 View Revisions
2014-07-29 15:35 Monsterovich Note Added: 0010086
2014-07-29 15:38 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 15:39 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 15:45 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 15:48 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 15:48 Monsterovich Note Edited: 0010073 View Revisions
2014-07-29 15:51 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 15:52 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:04 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:05 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:06 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:25 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:26 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:27 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 16:30 Monsterovich Note Edited: 0010086 View Revisions
2014-07-29 19:05 Edward-san Note Added: 0010089
2014-07-29 20:05 Monsterovich Note Added: 0010090
2014-07-29 20:08 Monsterovich Note Edited: 0010090 View Revisions
2014-07-29 20:09 Monsterovich Note Edited: 0010090 View Revisions
2014-07-29 20:56 Monsterovich Note Edited: 0010090 View Revisions
2014-07-30 03:39 Blzut3 Note Added: 0010096
2014-07-30 05:34 StrikerMan780 Note Added: 0010097
2014-07-30 05:35 StrikerMan780 Note Edited: 0010097 View Revisions
2014-08-02 22:13 Fastclick Note Added: 0010112
2014-08-03 16:04 Edward-san Note Added: 0010116
2014-08-03 19:07 StrikerMan780 Note Added: 0010118
2015-03-15 23:52 StrikerMan780 Note Added: 0011830
2016-01-21 14:33 StrikerMan780 Note Added: 0014144
2016-01-21 14:34 StrikerMan780 Note Edited: 0014144 View Revisions
2016-01-21 14:35 StrikerMan780 Note Edited: 0014144 View Revisions
2016-01-21 14:35 StrikerMan780 Note Edited: 0014144 View Revisions
2016-01-25 17:50 ibm5155 Note Added: 0014201
2016-01-25 17:54 StrikerMan780 Note Added: 0014203
2016-01-25 17:55 StrikerMan780 Note Edited: 0014203 View Revisions
2016-01-25 18:23 Korshun Note Added: 0014204
2016-01-25 20:10 StrikerMan780 Note Added: 0014205
2016-01-25 20:10 StrikerMan780 Note Edited: 0014203 View Revisions
2016-01-26 07:07 Torr Samaho Note Added: 0014206
2016-01-26 07:07 Torr Samaho Note Edited: 0014206 View Revisions
2016-01-26 07:08 Torr Samaho Note Revision Dropped: 14206: 0008572
2016-01-26 15:36 StrikerMan780 Note Added: 0014209
2016-01-26 15:37 StrikerMan780 Note Edited: 0014209 View Revisions
2016-01-26 15:38 StrikerMan780 Note Edited: 0014209 View Revisions
2016-01-26 15:38 StrikerMan780 Note Edited: 0014209 View Revisions
2016-01-26 19:17 Torr Samaho Note Added: 0014210
2016-01-26 20:48 StrikerMan780 Note Added: 0014211
2016-01-27 18:14 Torr Samaho Note Added: 0014212
2016-01-27 18:24 StrikerMan780 Note Added: 0014213
2016-01-27 18:25 StrikerMan780 Note Edited: 0014213 View Revisions
2016-11-24 10:54 Edward-san Note Added: 0016313
2016-11-25 00:14 Revilution Note Added: 0016315
2016-11-25 14:15 StrikerMan780 Note Added: 0016317
2016-11-25 17:26 Revilution Note Added: 0016318
2017-01-31 07:24 StrikerMan780 Note Added: 0016740
2017-01-31 07:25 StrikerMan780 Note Edited: 0016740 View Revisions






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker