Message Boards

  1. Odamex Message Boards
  2. Community Discussion
  3. General Discussion
  4. 32bpp color mode
Print
Pages: 1 [2] 3   Go Down

Topic: 32bpp color mode  (Read 68653 times)

Offline JamesDunne

  • Posts: 14
    • View Profile
Re: 32bpp color mode
« Reply #15 on: December 27, 2012, 06:41:19 »
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.
Logged

Offline JamesDunne

  • Posts: 14
    • View Profile
Re: 32bpp color mode
« Reply #16 on: December 27, 2012, 06:42:13 »
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.
Logged

Offline capodecima

  • Posts: 122
  • Brodamex Player
    • View Profile
Re: 32bpp color mode
« Reply #17 on: December 27, 2012, 06:49:32 »
I installed  VC2012 C++ , it say this error http://i.imgur.com/K2qJu.png
Logged

Offline JamesDunne

  • Posts: 14
    • View Profile
Re: 32bpp color mode
« Reply #18 on: December 27, 2012, 06:52:46 »
Try running without the launcher. Just double-click the odamex.exe in the folder.
Logged

Offline JamesDunne

  • Posts: 14
    • View Profile
Re: 32bpp color mode
« Reply #19 on: December 31, 2012, 01:44:37 »
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").
Logged

Ant P.

  • Nobody
Re: 32bpp color mode
« Reply #20 on: December 31, 2012, 17:44:28 »
With e2f7ea9 there's a compile error in lightScale():
Code: [Select]
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:
Code: [Select]
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.
Logged

Offline killingblair

  • Posts: 12
  • Odamechs
    • View Profile
Re: 32bpp color mode
« Reply #21 on: January 01, 2013, 21:01:52 »
Quote from: Ant P. on December 31, 2012, 17:44:28
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
Logged

Ant P.

  • Nobody
Re: 32bpp color mode
« Reply #22 on: January 02, 2013, 10:38:54 »
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.
Logged

Offline JamesDunne

  • Posts: 14
    • View Profile
Re: 32bpp color mode
« Reply #23 on: January 07, 2013, 13:39:17 »
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
Logged

Offline JamesDunne

  • Posts: 14
    • View Profile
Re: 32bpp color mode
« Reply #24 on: January 07, 2013, 14:07:55 »
Quote from: Ant P. on December 31, 2012, 17:44:28
With e2f7ea9 there's a compile error in lightScale():
Code: [Select]
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:
Code: [Select]
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.
Logged

Offline Ralphis

  • Administrator
  • Posts: 111
    • View Profile
Re: 32bpp color mode
« Reply #25 on: January 09, 2013, 15:49:28 »
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:





Logged

Offline 40oz

  • Posts: 14
  • [n. 'faw-dee']
    • View Profile
Re: 32bpp color mode
« Reply #26 on: January 10, 2013, 06:37:41 »
well its better than opengl :)
Logged

Ant P.

  • Nobody
Re: 32bpp color mode
« Reply #27 on: January 13, 2013, 11:38:50 »
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.
Logged

Offline XDelusion

  • Posts: 70
    • View Profile
Re: 32bpp color mode
« Reply #28 on: March 23, 2013, 16:17:41 »
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.
Logged
If we lost an eye we would be sad. So the Mother too is sad, and she'll end, and the world ends... - From the Heart of the World

Offline Pseudoscientist

  • Posts: 43
  • Peanut gallery
    • View Profile
Re: 32bpp color mode
« Reply #29 on: March 24, 2013, 08:00:13 »
Quote from: XDelusion on March 23, 2013, 16:17:41
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...
Logged
Sorry Guest, you are banned from using this forum!
Print
Pages: 1 [2] 3   Go Up
  1. Odamex Message Boards
  2. Community Discussion
  3. General Discussion
  4. 32bpp color mode