Jump to content
The Dark Mod Forums

revelator

Development Role
  • Posts

    1174
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by revelator

  1. Takes a while i know some things are pretty obvious but a few things like installing drivers can be a bit hard.
  2. hopefully final changes to get the linux build going again. Added missing glew initializer to linux specific code. split up qgl headers in os specific versions. Im unable to locate the opengl lib flags -lGL anywhere in scons or otherwise so i suspect it uses autodepend, but if you get any linker errors let me know.
  3. Not sure where in that map you took the shot but i have no such problems with the sky ?
  4. Should be fine with that card as its sufficiently new but by all means try it out.
  5. Ok removed some leftover code in gl_stub.cpp that is not needed anymore with GLEW, changes have been comitted, i hope it runs to the end now on linux
  6. If you have an older AMD gfx card you should turn it off since it does not work to well with those 5x series and older atleast as far as i know. Hmm have not touched anything in the skybox code curious ? not sure what causes that effect. Experimental branch is mostly a cleanup project, making a solid code base from where the devs can start adding in the funny stuff a few optimizations might also happen but mostly its to get rid of outdated cruft, correcting some mistakes in the code, and generally shining this thing up with a bit of spit and polish.
  7. Noticed that as well the old one seems a bit more grainy when looking at the wall textures, though im not sure if its caused by me not having the 100% same location when taking the shot.
  8. Just to blow it totally out the window heres a shot with 16x aniso 16x antialiasing adaptive vsync and all the gfx shebang i could enable. Me card still likey but atleast now it shows some fps dropout.
  9. Toatally agree Steve this is just the groundwork
  10. Ok as close as i could get but non conclusive as i waries a lot dependent on location, Old TDM New TDM
  11. Ok created replacement functions for linux and other unix based OS that do not have these, changes have been comitted. Cant exactly tell if theres a real FPS increase since the old version of the FPS counter puts out some wildly varying values compared to the new one, but as far as i could see the old fps counter variated between 47 to 63 fps so there might be some small increase measurable.
  12. Allmost same location just a different angle was trying to avoid a guard while i took it hehe. _aligned_malloc / _aligned_free do not exist on linux i found out :S but could make a replacement from my GC wrapper, lets see what i can come up with.
  13. sure hang on need to get the default engine back with the updater P.s i removed a few of the old fallback backends like the arb and nv10 renderers as well as the hardcoded light and texcoord generation caches for cards not able to do shaders = nv10 and older. I kept the r200 renderer because it still works pretty well even on my R270x though the shadows are non shader based with this renderer, i havent tested the nv20 render path as it doesn't apply to my card and would most likely crash with it, but if someone has a nvidia try out r_renderer nv20.
  14. blackbog hollow on darkmod with GLEW backend and GC garbadge collector running, all effects on.
  15. Huh ok just checked and its was not even defined for the linux build because i forgot to apply it. Fixed now comitting changes.
  16. agh yeah gcc hates it when a type or macro is defined in two places gotta have a look at the second macro and see if it matches the other one, if it does move it to sys_public.h and make it global, That should take care of that, if not define it to something else and rename the instances where its used to the new name then hope i catched all of em.
  17. Btw anyone else noticed that there seems to be a bug in the script animation for the broadsword ? whenever i select that weapon the animation halts funny enough when it happens the soldiers cannot use there swords either so lol.
  18. Fixed another one that would break linux builds, since my GC interface was not prepared for linux yet i have made a few changes so that it only gets enabled if we are using MSVC. Added replacements to public compiler defines in sys_public.h also added workarounds for some missing interfaces. changed the PACKED macro into a unified version that works for all architectures. Had to make a few changes to sound_local.h as well as a result of this.
  19. Ok made a stupid mistake in inlining i had all inlines set to force inline thats why it failed on linux, fixed on trunk now. added teIs fix for glew, also comitted.
  20. And @teIs oki had no idea that you need to include the standard glew.h before the glxew.h so thanks ill commit it immediatly. also notice that the glew lib is missing from the scons build so ill look at getting that one in as well. As for removing the old render backends i was not sure if you wanted that but its pretty easy to do as long as you remember that there are a few things in some places you dont expect specifically written to support them that needs removing, i have completely removed all the code for the old backends in revelation so i could just copy of my changes from there. Also there are a few lines of code that needs to be rewritten (just for overbrights).
  21. recursive inlining sigh guess theres still some work to do on getting it to compile on linux.
  22. Well its not really up to me but if i where to go about it i would focus on first routing out known bugs to vanillas code, luckily 90% of these have allready been fixed by projects such as dhewm3. Next collect devs to hear what they would like to see implemented and discussing which part we should focus on first. This part could be finding optimization spots as well as effects but focus should be on keeping the engine in a running condition on hardware that may go some years back, after that we can focus on eyecandy. Some teams could then focus on game logic, while us rendering nerds could focus on new effects, and the allround wizards could help a bit on everything including optimization. Im mostly a render nerd but i have enough common knowledge to also do work on other parts of the engine (not so much game logic) but if i have an idea i will usually run it by the people who do before i break stuff.
  23. Also made me cringe but at the time i could not get it working correctly with just abs :S not sure if its a bug with msvc's libraries but abs alone output wildly incorrect values for some reason. my 2 gb card would report 800 mb so i resorted to using the value = -value; and keeping the abs as a fallback. Could probably just remove the abs completely instead. i suspect as much you need the glew developer package for your distro, or a precompiled linux version, should probably make a seperate linux specific version of qgl.h also,looks rather strange to have something with win in the name as part of a linux compile hehe. EFX should be easy its part of openal soft and a replacement for the old dsound based EAX backend no need for SDL there
  24. Sure anything you dont want from dhewm3 ? changing to SDL would break my GLEW port so im not sure how i should react to that part, besides i prefer using native OpenGL and no other part of the engine really needs anything special since all the libraries used in it are allready crossplatform. Changing to use cmake would be a great leap though and we get rid of a lot of deprecated stuff in the process . Nothing agains scons its a great build system but it can be a little clunky at times and cmake works for all OS so its really a no brainer. All devs who want to have access to my git repository to make direct changes are welcome to chime in the more of us the faster it goes.
×
×
  • Create New...