Anonymous | Login | Signup for a new account | 2024-04-25 01:59 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0001541 | Zandronum | [All Projects] Bug | public | 2013-10-14 05:39 | 2017-01-31 07:25 | ||||||||
Reporter | StrikerMan780 | ||||||||||||
Assigned To | |||||||||||||
Priority | high | Severity | major | Reproducibility | always | ||||||||
Status | confirmed | Resolution | open | ||||||||||
Platform | PC | OS | Windows 7 | OS Version | Ultimate x64 | ||||||||
Product Version | 1.2 | ||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0001541: Models not in view/obscured by map geometry are still rendered, causing massive FPS annihilation. | ||||||||||||
Description | As 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 Reproduce | Load 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 | treetest.pk3 [^] (1,074,700 bytes) 2013-10-14 05:39 | ||||||||||||
Notes | |
(0007405) StrikerMan780 (reporter) 2013-10-14 05:43 |
I'll make another test to see if completely sealed walls produce the same result. |
(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. |
(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.) |
(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? |
(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. |
(0009401) Watermelon (developer) 2014-06-15 14:53 |
Definitely can confirm this, it ruined a mod idea I had |
(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 |
(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. |
(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.
I think, he seriously needs a doctor. |
(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? |
(0010079) Monsterovich (reporter) 2014-07-29 10:56 edited on: 2014-07-29 11:19 |
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 (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. |
(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. |
(0010085) Edward-san (developer) 2014-07-29 13:41 edited on: 2014-07-29 13:41 |
Quote Come on, you can find a decent and cheap video cards which have at least OpenGL 3.x support. Quote 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 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 (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 |
(0010089) Edward-san (developer) 2014-07-29 19:05 |
Quote Sorry, but it doesn't sound too much time (6 years is a lot)... Quote Since GPUs can't do math (except for GPGPU cards), CPUs have to do it, hence the CPU bottleneck. QuoteIt 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 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 (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 [^]' |
(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. |
(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.) |
(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 ? |
(0010116) Edward-san (developer) 2014-08-03 16:04 |
Still, what about the latest builds of gzdoom on drdteam site? Still the same problem? |
(0010118) StrikerMan780 (reporter) 2014-08-03 19:07 |
Same problem. |
(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? |
(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. |
(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 |
(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. |
(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. |
(0014205) StrikerMan780 (reporter) 2016-01-25 20:10 |
Yeah. It's basically what I've tried explaining in previous posts. |
(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. |
(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. |
(0014210) Torr Samaho (administrator) 2016-01-26 19:17 |
Quote from StrikerMan780 Nice! Quote from StrikerMan780 That should all be in src/gl/models/gl_models.cpp. Quote from StrikerMan780 The VC++ 2005 guide on the Wiki should still be fine. If you have problems compiling, just let me know. |
(0014211) StrikerMan780 (reporter) 2016-01-26 20:48 |
I use Visual Studio 2015 CE. I can't run VS2005. |
(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 [^]' |
(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. |
(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. |
(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. |
(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). |
(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. |
(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. |
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 |
Copyright © 2000 - 2024 MantisBT Team |