Odamex Message Boards
Community Discussion => General Discussion => Topic started by: JamesDunne on December 24, 2012, 22:08:43
-
Hey everyone,
I've been working on the 32bpp color port of the Odamex client for the last week or so. I just wanted to "officially" throw this out there for everyone to help test out. Let us know what you think!
This 32bpp port only enhances the rendering portion of the game; i.e. it does not affect how textures or sprites are loaded. 32bpp removes the need for color-mapping which is what the 8bpp mode uses to find the "best" color among the 256 available colors for the lighting effect. 32bpp mode just uses the raw RGB value of the darkened color for lighting and thus you won't see any aliasing effects (e.g. colors shifting hue from red to brown).
Latest binary (Win32) is here:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-71dcc38.zip
You can find future binaries (check Last Modified date stamp) here, and the required SDL dlls:
http://bittwiddlers.org/ftp/jim/software/odamex/
In order to use these binaries you'll need the VC2012 C++ redistributable for x86 platform installed. You can download it here. Be sure to pick x86!
http://www.microsoft.com/en-us/download/details.aspx?id=30679
I have all the code up on my GitHub repository at:
https://github.com/JamesDunne/odamex
There is a README-32bpp file included in the ZIP package which documents what has changed and what issues are known.
If you're looking for a quick test, just go to the Video Options menu screen and flip "32-bit color" to "Yes". The change should take effect immediately. For an even quicker way, use the console (~) and type "vid_32bpp 1" to enable and "vid_32bpp 0" to disable (i.e. go back to 8bpp).
All vanilla DOOM and DOOM 2 maps are working.
Please help by testing out custom PWADs with extra BOOM effects enabled, e.g. ACS scripting, custom lighting, translucency, etc.
Also, please report any significant performance loss while in 32bpp compared to the 8bpp mode. Use `vid_fps 1` to show the FPS counter in the lower-left corner of the screen and report those numbers, along with which PWAD and map.
-
I have to say, this is amazing and I am very happy you did this. I am very appreciative of your work and am anxious to see what you come up with next as well :)
Of course I will be playing with this and reporting any bugs I come across.
Also how about some screenshots??
http://www.facebook.com/media/set/?set=oa.10151156938562007&type=1
-
Just implemented SSE2 optimizations to make 32bpp alpha-blending insanely fast. I don't get any slowdowns from the full 35fps in 1920x1080 with full-screen translucency effects now.
Latest Win32 build:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-ae4f6d9.zip
-
A few bugs:
(http://i.imgur.com/kXF2Y.jpg)
All player color icons appear a shade of blue in the scoreboard despite them being different colors.
(http://i.imgur.com/JeWKz.jpg)
Translucency effects appear to not be as translucent anymore? zddl4.wad (http://static.totaltrash.org/wads/zddl4.wad) map00 for testing
Oh no! IDL2013l.wad (http://grandpachuck.org/files/wads/idl2013l.wad) now includes rainbow road!
(http://i.imgur.com/goV8Z.png)
It's supposed to look like this. This screenshot was taken in 0.6.2 release:
(http://i.imgur.com/iUHit.png)
map11 has a few issues with rendering these textures.. not sure what the problem is. They also appear tutti frutti in 8-bit mode in your modified client:
(http://i.imgur.com/sNQFH.png)
This screenshot is what it is supposed to look like. It was taken with 0.6.2 released:
(http://i.imgur.com/KcSh1.png)
Also in map11 of idl2013l, dying in the slime shows a great testcolor green screen! This is actually worse when you switch back to 8-bit mode in your modified client... because then it turns tutti frutti and crashes:
(http://i.imgur.com/Ysy8J.png)
This screenshot was taken in 0.6.2 release. This area is supposed to look like this:
(http://i.imgur.com/HlqKk.png)
Last but not least, particle fountains are rendered in tutti frutti! Cool, but not intentional:
(http://i.imgur.com/nS530.png)
By the slime the particle fountains are green, right in front of me where the SG pickup is they are supposed to be blue. This is idl2013l map29
-
Looks really nice, but ae4f6d9 runs at about 25fps for me (on doom 2 demo 1 @ 1280x720). Callgrind says 35% of the total time is in rt_draw4cols(), ~20% in the SSE2 code. Using GCC 4.6.3 on amd64.
-
GCC does not impress me with its performance. I really don't have much to tell you on that one.
-
GCC does not impress me with its performance. I really don't have much to tell you on that one.
Just a note, official binaries are built with gcc.
-
Yeah I know :P. I wonder if GCC is not inlining the SSE2 functions. I really wanted to avoid copy/pasting all that code 4 times. Maybe a macro would suffice then.
-
Latest build should fix most of those issues listed above:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-31a372f.zip
Remaining issues are:
- Scoreboard colors
- Translucent parts have bright/dark vertical stripes in them
-
Forget what I posted, I'm retarded.
I compiled it without setting C[XX]FLAGS properly. CMake's system is weird. Runs perfectly now that I'm actually using -O2.
-
Ant P. - haha. No worries.
Try to build the bleeding edge, commit id 65f3f3c93bc13a40b273e339162225bdb879f7f9 on my GitHub https://github.com/JamesDunne/odamex
Latest Win32 build: http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-65f3f3c.zip
-
I've been playing with `bind mouse3 "toggle vid_32bpp"`, it's pretty cool flipping back and forward between them.
Anyway here's all the feedback I've got so far:
- The distance fog/light fade gradient still has sharp steps (they're most visible on flats). Any plan to change that?
- You've probably noticed already, the transparent menu background rectangles get shifted to the right in 32-bit mode.
- Changing the brightness (F11) doesn't work.
- Haven't tried this with the newest revision, but the server build's broken (looks like dead code to me, but I'm not a C++ expert)
Also, thought you might like to know it runs fine under clang too. :)
-
Thanks for that. Already discovered and fixed most of that.
Latest Win32 build:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-28182dd.zip
Yeah I can't get the server EXE to build either.
There are only 32 distinct light levels. I'd like to make the lighting more smooth. This concept of light levels is spread throughout the code and would be tough to factor out.
-
Latest Win32 build fixes all known issues to date:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-007e46b.zip
-
how run it ? i tried just replace odamex.exe with this new exe file and it say some error :o .
-
Read the original post. You probably need the VC2012 C++ redistributable for x86 installed. Link is in the original post.
Please describe the exact error message when reporting errors; just saying "some error" is not helpful. FYI, Windows message boxes (e.g. OK/Cancel) can usually have their contents copied to the clipboard with CTRL-C while the box is showing.
-
Latest Win32 build:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-7bff4a0.zip
Last build had a regression with fullbright things in 8bpp and 32bpp, and gamma regressed in 32bpp. This fixes those regressions.
-
I installed VC2012 C++ , it say this error http://i.imgur.com/K2qJu.png
-
Try running without the launcher. Just double-click the odamex.exe in the folder.
-
Latest builds; should be faster for status/pain blending:
x64:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-e2f7ea9-x64.zip
x86
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-e2f7ea9-x86.zip
Changes:
Introduced `i_wait` cvar to control frame rate. Set to 0 to remove the 35fps rendering cap. Set back to 1 for original behavior.
Introduced `vid_vsync` cvar to control vsync. Default is 1.
Introduced `r_optimize` cvar to control which CPU vectorization features are used for status color blending. Use any one of "sse2", "mmx", "altivec", or "none". Use "detect" (default) to detect what's available and switch to the most optimal.
NOTE: Leaving `i_wait` at "1" (default) will help reduce CPU % and avoid overheating. Using it at "0" will help vid_fps report much more accurate (and not limited to 35) fps numbers.
If you have bad performance, please report the following pieces of information from the console (press ~):
vid_currentmode
i_wait
r_optimize
Also make sure `vid_fps` is "1" and read the number that appears on the bottom-left of the screen. When reporting fps, be sure you've got `i_wait` set to "0" to get numbers beyond 35fps.
Finally note what OS and which binary you're running (the ZIP filenames have 7-digit identifiers like "e2f7ea9" and a suffix like "-x64" or "-x86").
-
With e2f7ea9 there's a compile error in lightScale():
odamex/client/src/v_palette.cpp:516:77: error: no matching function for call to ‘clamp(double, float, float)’After fixing that I get a crash on startup:
odamex/client/src/r_draw.cpp:2029: void R_InitDrawers(): Assertion `rt_copy4colsD != __null' failed.
Also (this is an upstream problem, but really annoying) Git keeps throwing stupid errors because some of the files have wrong line endings. If anyone knows how to turn that off or can go fix those in svn it'd be nice.
-
Also (this is an upstream problem, but really annoying) Git keeps throwing stupid errors because some of the files have wrong line endings. If anyone knows how to turn that off or can go fix those in svn it'd be nice.
Try:
git config --global core.autocrlf true
-
I guess it's not only an upstream thing... there's a .gitattributes file making it convert line endings. That's overriding any local config I try to use.
-
Ah yeah sorry about the .gitattributes. I was trying to make it forcibly check in LF line endings that way to be compliant with the coding standards. I'm pretty sure it does.
In order to clean things up do a `git reset --hard`. That should hopefully check out the line endings in a clean way. I think do it without the core.autocrlf set to true. The git documentation does not make things clear.
Latest 32bpp builds:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-2c26fdf-x64.zip
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-2c26fdf-x86.zip
-
With e2f7ea9 there's a compile error in lightScale():
odamex/client/src/v_palette.cpp:516:77: error: no matching function for call to ‘clamp(double, float, float)’After fixing that I get a crash on startup:
odamex/client/src/r_draw.cpp:2029: void R_InitDrawers(): Assertion `rt_copy4colsD != __null' failed.
Both of these code issues have been resolved. MSVC did not complain about the clamp() usage but GCC did. Also recent code changes obviated the assertions out.
-
A small test map I made to show off how the new true color mode can make maps look. The first picture in each shot is in the 8-bit color, the second is the new true color:
(http://ralphis.unidoom.org/stuff/img/odamex/odan1_8.png)
(http://ralphis.unidoom.org/stuff/img/odamex/odan1_32.png)
(http://ralphis.unidoom.org/stuff/img/odamex/odan2_8.png)
(http://ralphis.unidoom.org/stuff/img/odamex/odan2_32.png)
-
well its better than opengl :)
-
Is there a "stable version" source tarball available? Current HEAD doesn't compile under Linux at all, and it's impossible to checkout any other revisions because of the line endings problem.
-
Correct me if I am wrong but will this allow me to replace my old textures with the 256 color palette limit with textures with more than 256 colors? If so, how do I load them into my pWAD so that they will show up in Odamex as intended rather then being all black? Seems the only way to make it display (that I can find) is to convert them to my custom 256 color paltte.
-
Correct me if I am wrong but will this allow me to replace my old textures with the 256 color palette limit with textures with more than 256 colors?
AFAIU, not yet...
-
Darn, I was hoping that that was what all this was leading up to. Working in 256 colors can be quite the pain in the butt some times.
BTW, I can't download the latest version of this Odamex, the links appear to be dead so I had to settle for an older one.
-
Why don't you try build it from source yourself?
-
I wouldn't know where to begin...
...that' something I should set aside some time to learn.
-
You begin here: http://odamex.net/wiki/How_to_build_from_source
Since you want to build from SVN, you'll need a SVN client too.
32bpp mode right now lives in rend32 branch.
-
When I can get the pages to the source to load, I see a multitude of files, but no archives. I take it I have to download every file individually and place them all in the same directory?
-
This page:
http://odamex.net/svn/root/branches/
Keeps giving me this message:
XML Parsing Error: no element found
Location: http://odamex.net/svnindex.xsl.php
Line Number 170, Column 3:
It seems that your post got flagged as spam due to links. Here's a tip: post w/o links first, then edit them in. Thus you'll bypass the filter. (How links to odamex.net can be spam is beyond me.)
That page works for me after a refresh. But you're supposed to access it with a SVN client anyway.
When I can get the pages to the source to load, I see a multitude of files, but no archives. I take it I have to download every file individually and place them all in the same directory?
No, you're supposed to use a SVN client. I personally use this (http://www.sliksvn.com/en/download) on Windows but you can use something else.
-
Hey, there's my post, I was wondering where that went!
Where was it?!?! :)
-
Hey, there's my post, I was wondering where that went!
Where was it?!?! :)
No idea. I got it out of "Thread Summary" below the text box which appears when you reply to thread (not Quick Reply).. Also they are visible when viewing "recent posts" on the main forums page.
Here's a link to docs for command-line SVN client:
http://svnbook.red-bean.com/en/1.7/svn.tour.initial.html