Duke4.net Forums: EDuke32 2.0 and Polymer! - Duke4.net Forums

Jump to content

  • 212 Pages +
  • « First
  • 176
  • 177
  • 178
  • 179
  • 180
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 2.0 and Polymer!  "talk about the wonders of EDuke32 and the new renderer"

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5311

Flat sprites are dislocated in Polymost mode, which creates see-through holes in structures.

http://i.imgur.com/uw0CmgD.png

This post has been edited by Fox: 20 August 2015 - 12:27 PM

0

User is offline   Jblade 

#5312

when using the save command the game changes the quicksave slot to whatever slot was specified in the command - any way to fix this so the player's choice of quicksave slot isn't overridden?
2

#5313

Hi all. I have problems with the launch of the polymer (in eduke32.exe and mapster32.exe) in the 5298 revision or older. The game is interrupted immediately after the start. Last log message:

Initializing Polymer subsystem ...
g_errorLineNum: 0, g_tw: 0


The problem occurs only when using a polymer mode. Revision 5297 is working correctly.
Graphic card is integrated Intel Intel® HD Graphics 2.1.0 - Build 8.15.10.2993

Attached File(s)


0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5314

Does Mapster still uses the x-y offset for ROR?
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#5315

View PostFox, on 11 September 2015 - 04:52 PM, said:

Does Mapster still uses the x-y offset for ROR?

Yes, in the non-Lunatic EDuke32 build, the sector's {ceiling,floor}xpanning member is used to hold the bunch number of the ceiling or floor.
0

User is offline   Micky C 

  • Honored Donor

#5316

And IIRC you can't save TROR maps in the lunatic build :)
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5317

View PostHelixhorned, on 20 September 2015 - 04:30 AM, said:

Yes, in the non-Lunatic EDuke32 build, the sector's {ceiling,floor}xpanning member is used to hold the bunch number of the ceiling or floor.

Is there anything that prevents non-Lunatic build from having new structures in the map format? Or is it a matter of the classic Build engine code being too messy?

This post has been edited by Fox: 20 September 2015 - 08:53 AM

0

User is offline   Micky C 

  • Honored Donor

#5318

I think a big part of it is that the lunatic map files can be extended without having to increment the map version number, by using reasonable default values for new structures, being some kind of text-based format.

I'd guess there must be something stopping the current map system from adding new stuff in otherwise Helix wouldn't have used the offsets for TROR in the first place.

This post has been edited by Micky C: 20 September 2015 - 03:58 PM

0

User is offline   TerminX 

  • el fundador

  #5319

View PostMicky C, on 20 September 2015 - 03:53 PM, said:

I'd guess there must be something stopping the current map system from adding new stuff in otherwise Helix wouldn't have used the offsets for TROR in the first place.

OK, you know how every time we change something internally, savegames break? Imagine that but with map files. We'd end up with thousands of lines of compatibility code to support loading every map version we ever went through, and everyone would end up with maps that only worked in EDuke32/Mapster32 and could never be altered by any other existing utility again. That would be bad.
3

User is online   LeoD 

  • Duke4.net topic/3513

#5320

make RENDERTYPE=WIN fails as of r5352:
build/src/winlayer.c: In function 'void UninitDirectInput()':
build/src/winlayer.c:1161:59: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
         for (i=joynumaxes-1; i>=0; i--) Bfree(axisdefs[i].name);
                                                           ^
In file included from build/src/winlayer.c:31:0:
C:/Progs/mingw64/x86_64-w64-mingw32/include/malloc.h:77:16: note:   initializing argument 1 of 'void free(void*)'
   void __cdecl free(void *_Memory);
                ^
build/src/winlayer.c:1166:64: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
         for (i=joynumbuttons-1; i>=0; i--) Bfree(buttondefs[i].name);
                                                                ^
In file included from build/src/winlayer.c:31:0:
C:/Progs/mingw64/x86_64-w64-mingw32/include/malloc.h:77:16: note:   initializing argument 1 of 'void free(void*)'
   void __cdecl free(void *_Memory);
                ^
build/src/winlayer.c:1171:58: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
         for (i=joynumhats-1; i>=0; i--) Bfree(hatdefs[i].name);
                                                          ^
In file included from build/src/winlayer.c:31:0:
C:/Progs/mingw64/x86_64-w64-mingw32/include/malloc.h:77:16: note:   initializing argument 1 of 'void free(void*)'
   void __cdecl free(void *_Memory);
                ^
Failed building build/obj/winlayer.o from build/src/winlayer.c!
makefile:626: recipe for target 'build/obj/winlayer.o' failed
mingw32-make: *** [build/obj/winlayer.o] Error 1


This post has been edited by LeoD: 24 September 2015 - 11:50 AM

0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5321

View PostTerminX, on 21 September 2015 - 11:04 AM, said:

OK, you know how every time we change something internally, savegames break? Imagine that but with map files. We'd end up with thousands of lines of compatibility code to support loading every map version we ever went through, and everyone would end up with maps that only worked in EDuke32/Mapster32 and could never be altered by any other existing utility again. That would be bad.

But wouldn't it make sense if you could only open ROR maps with Eduke/Mapster? As a last resort, Mapster could have the option to export ROR maps without the ROR data. The lack of y-xpannign is what prevents me from releasing a ROR map. You may think it's nitpicking, but I want my E1L3 with transparent water to have the correct texture alignment.

Also I don't understand why it has to use x-ypanning instead of the sector extra, since it's a structures unused by the map editor and has the same amount of bits. The only reason I can think of is that it was thought at the time that some existing mod could be using it. But that wouldn't have been a good decision, since the alternative is to prevent textures from being properly aligned, and the sector extra is not accessible via CON (the value is overwritten before any game event can read it) so no mod has ever used it.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#5322

Quote

Also I don't understand why it has to use x-ypanning instead of the sector extra, since it's a structures unused by the map editor and has the same amount of bits.

sector[].extra is used in Duke3D game logic: it's the lotag of the GPSPEED sprite found in it, or 256 by default.

View PostFox, on 24 September 2015 - 03:02 PM, said:

I want my E1L3 with transparent water to have the correct texture alignment.

If you have the sectors of the water area in one bunch, the floor textures will be aligned to each other, although they will have "arbitrary" global alignment, assuming no wall-relative alignment. I agree that it's a bug that the renderer still regards the panning value when it's actually a bunch index -- it could be made to have a fixed panning such as 0 then. Even if you have to split one sector into multiple bunches (for example because you want every one of them to be convex for the classic renderer's sake), if you end up small panning differences (say 1 to 5), it shouldn't be noticeable at a casual glance.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5323

View PostHelixhorned, on 25 September 2015 - 09:42 AM, said:

sector[].extra is used in Duke3D game logic: it's the lotag of the GPSPEED sprite found in it, or 256 by default.

AFAIK, after the map is loaded the sector bunchs are stored in the floorbunch and ceilingbunch structures, so it should't conflict with GPSPEEDs.

This post has been edited by Fox: 25 September 2015 - 10:06 AM

0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#5324

View PostFox, on 25 September 2015 - 10:05 AM, said:

AFAIK, after the map is loaded the sector bunchs are stored in the floorbunch and ceilingbunch structures, so it should't conflict with GPSPEEDs.

Well, these structures are present in the Lunatic build. The GPSPEED sprites are deleted after premap, sector[].extra stays.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5325

Even so, is it not doable? The game already store sector/wall/sprite data in the memory (i.e. cyclers and mirrors), and I believe that would be a preferable option than eliminating the texture panning.

This post has been edited by Fox: 25 September 2015 - 10:59 AM

1

User is offline   Jblade 

#5326

I just checked the synthesis notes and saw some stuff pertaining to palettes:
------------------------------------------------------------------------
r5352 | hendricks266 | 2015-09-23 10:55:31 -0700 (Wed, 23 Sep 2015) | 1 line

Remove NULL checks before calling free(): they are unnecessary as per the C standard. Other cleanup includes factoring code into DO_FREE_AND_NULL() macros.
------------------------------------------------------------------------
r5351 | hendricks266 | 2015-09-23 10:55:19 -0700 (Wed, 23 Sep 2015) | 1 line

Defs: Add basepalette, palookup, and blendtable tokens.
------------------------------------------------------------------------
r5350 | hendricks266 | 2015-09-23 10:55:15 -0700 (Wed, 23 Sep 2015) | 1 line

Defs: Prevent tilefromtexture from ever assigning index #255 (the transparent color) to the processed image.
------------------------------------------------------------------------
r5349 | hendricks266 | 2015-09-23 10:55:11 -0700 (Wed, 23 Sep 2015) | 1 line

Internally, work with 24-bit palettes instead of 18-bit.
------------------------------------------------------------------------
r5348 | hendricks266 | 2015-09-23 10:55:02 -0700 (Wed, 23 Sep 2015) | 1 line

Restructure the basepaltable subsystem to support up to 256 palettes and use dynamic allocation like palookup and blendtable.

Just curious, what stuff can this be used for?
0

User is offline   TerminX 

  • el fundador

  #5327

It's used for setting up a new palette, appropriate blending table, and alternate palettes with .def instead of with palette.dat, etc.
1

User is offline   Jblade 

#5328

Oh cool - by alternate palettes, do you mean the whole screen palettes like water and night vision? Does this mean I can use many more full screen palette replacements now, or is it just the pal numbers like 21 and stuff? Having many more full screen palette options is something I've been waiting for a long long time.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5329

It's for everything. Palettes for the whole screen, pal numbers, shade tables, fancy effects with fogpals, etc.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5330

View PostJblade, on 27 September 2015 - 05:55 AM, said:

Oh cool - by alternate palettes, do you mean the whole screen palettes like water and night vision?

Basepalettes are included, and I have raised the cap from 7 to 256. I am going to write a wiki tutorial explaining how everything works once I write a new Buildtool to apply our tilefromtexture color match algorithm to an input file (because I've found IrfanView, GIMP, and Photoshop to all suck at this particular task).

If you want a taste, this is the code to load everything from PALETTE.DAT and LOOKUP.DAT:

basepalette 0 { raw { file "PALETTE.DAT" shiftleft 2 } }
palookup 0 { raw { file "PALETTE.DAT" offset 770 } }
blendtable 0 { raw { file "PALETTE.DAT" offset 8962 } }

palookup 1 { raw { file "LOOKUP.DAT" offset 2 noshades } }
palookup 2 { raw { file "LOOKUP.DAT" offset 259 noshades } }
palookup 6 { raw { file "LOOKUP.DAT" offset 516 noshades } }
palookup 7 { raw { file "LOOKUP.DAT" offset 773 noshades } }
palookup 8 { raw { file "LOOKUP.DAT" offset 1030 noshades } }
palookup 3 { raw { file "LOOKUP.DAT" offset 1287 noshades } }
palookup 4 { raw { file "LOOKUP.DAT" offset 1544 noshades } }
palookup 5 { raw { file "LOOKUP.DAT" offset 1801 noshades } }
palookup 9 { raw { file "LOOKUP.DAT" offset 2058 noshades } }
palookup 10 { raw { file "LOOKUP.DAT" offset 2315 noshades } }
palookup 12 { raw { file "LOOKUP.DAT" offset 2572 noshades } }
palookup 13 { raw { file "LOOKUP.DAT" offset 2829 noshades } }
palookup 15 { raw { file "LOOKUP.DAT" offset 3086 noshades } }
palookup 16 { raw { file "LOOKUP.DAT" offset 3343 noshades } }
palookup 18 { raw { file "LOOKUP.DAT" offset 3600 noshades } }
palookup 19 { raw { file "LOOKUP.DAT" offset 3857 noshades } }
palookup 11 { raw { file "LOOKUP.DAT" offset 4114 noshades } }
palookup 14 { raw { file "LOOKUP.DAT" offset 4371 noshades } }
palookup 17 { raw { file "LOOKUP.DAT" offset 4628 noshades } }
palookup 20 { raw { file "LOOKUP.DAT" offset 4885 noshades } }
palookup 21 { raw { file "LOOKUP.DAT" offset 5142 noshades } }
palookup 22 { raw { file "LOOKUP.DAT" offset 5399 noshades } }
palookup 23 { raw { file "LOOKUP.DAT" offset 5656 noshades } }
palookup 24 { raw { file "LOOKUP.DAT" offset 5913 noshades } }
palookup 25 { raw { file "LOOKUP.DAT" offset 6170 noshades } }
basepalette 1 { raw { file "LOOKUP.DAT" offset 6426 shiftleft 2 } }
basepalette 2 { raw { file "LOOKUP.DAT" offset 7194 shiftleft 2 } }
basepalette 4 { raw { file "LOOKUP.DAT" offset 7962 shiftleft 2 } }
basepalette 3 { raw { file "LOOKUP.DAT" offset 8730 shiftleft 2 } }
basepalette 5 { raw { file "LOOKUP.DAT" offset 9498 shiftleft 2 } }


Note that I don't recommend concatenating multiple datasets in a single file for anything new.
2

User is offline   Jblade 

#5331

Any reason why the wall colours have changed in the latest mapster snapshots? A blocking wall is red now.
0

#5332

View PostJblade, on 11 October 2015 - 11:54 PM, said:

Any reason why the wall colours have changed in the latest mapster snapshots? A blocking wall is red now.


There is a bit of purple - it is flashing between red and purple instead of being pulsating purple as it should be. If it's not an accident then I have to ask the question why change something that was fully functional previously.

I suspect it is a bug though, as I just drew a square, divided it diagonally and got a white wall. Clearing blocking bit made the line red, setting it again made it pulsate red/<->purple.

TTFN,
Jon

Attached thumbnail(s)

  • Attached Image: white-wall.png
  • Attached Image: red-blocking-wall.png

0

User is offline   Jblade 

#5333

Quote

-Cstat 1024 now activates a special drawing mode that indicates a sprite should be drawn without depth after all other sprites have been drawn. The previous cstat 1024 functionality, an internal hack for shadows cast by models in Polymost, has been moved to bit 1 of a new graphical effects bitfield stored in a tsprite's .extra member.

I saw this in the changelog, and testing it ingame it works great and will help fix a lot of ugly flickering we had with glow sprites and stuff. Thanks a lot for adding it in!
2

User is offline   TerminX 

  • el fundador

  #5334

The cstat bit that activates it may change, so keep on the look out for that if it happens. It's also not working correctly in Polymer, which means Polymer itself isn't working correctly currently since the new flag is applied to the built-in stuff like explosions. Damn it, if it's not one thing it's another. :)
5

User is offline   Danukem 

  • Duke Plus Developer

#5335

Thanks for the warning -- I've finally learned my lesson about using unfinished features (don't).
0

User is online   NightFright 

  • The Truth is in here

#5336

I wanted to give a big thumbs-up to the EDuke32 coding team for implementing the latest Polymer menu feature that allows you to toggle dynamic lighting (among other things), including a "smart" way of keeping hidden switches hidden by deactivating lights in such cases. A very useful feature, especially for those who don't like to use console commands!

This post has been edited by NightFright: 26 October 2015 - 06:45 AM

3

#5337

Didn't think this was worthy of it's own topic, so I'll post it in here. In eDuke 5400 lately I noticed that the laser tripmines are the solid red color instead of the more fancy looking translucent color. I remember from looking in the con file of a mod recently that you can change that in the con settings. I don't have any con files in my eduke folder, so is there a console command to change that, or some other way to fix that setting back to the better looking way? Thanks.
0

User is offline   Mark 

#5338

If you know which lines of code are needed from that modded con file you can copy / paste them into your own new con file. Call the new file tripmine.con and put it in the main Eduke folder. Then edit the duke3d.def file and add the line " include tripmine.con " without the quotation marks. If all is well with the code you copied it should do what you want. If you get an error message it means you didn't grab all the proper code from that modded con file. You may have a problem if that original con file tries to use a new texture that you do not have in regular Eduke.

This post has been edited by Mark.: 29 October 2015 - 11:19 AM

2

#5339

View PostMark., on 29 October 2015 - 11:16 AM, said:

If you know which lines of code are needed from that modded con file you can copy / paste them into your own new con file. Call the new file tripmine.con and put it in the main Eduke folder. Then edit the duke3d.def file and add the line " include tripmine.con " without the quotation marks. If all is well with the code you copied it should do what you want. If you get an error message it means you didn't grab all the proper code from that modded con file. You may have a problem if that original con file tries to use a new texture that you do not have in regular Eduke.

Am I mistaken or was the translucent look the default before? I wonder why it's no longer the default for me, if so?

To be honest I did try making a con file last week messing with various stuff, and it didn't work, it would always say there was a bunch of mistakes when trying to load. And I'm sure there were. :)

Is there a default template somewhere? I read the wiki page on con editing didn't quite get me there.

This post has been edited by PsychoGoatee: 29 October 2015 - 11:49 AM

0

User is offline   Mark 

#5340

Looking at the wiki, other people's mods, asking questions and LOTS of trial and error has gotten me to the point of knowing enough con coding to do a bunch of the "easier" things in my projects. Keep at it. I gave up a few times before it finally started to sink in. It would be fantastic if there were lots and lots of code "snippets" or examples to go along with the technical info in the wiki. There are already some very useful ones in there but many more are needed. Sometimes it seems that the wiki was written assuming basic knowledge of cons and you can get lost if just starting out. Like most others here with the knowledge to add some examples, I'm so busy with upcoming projects that adding to the wiki is a low priority for me. I would like to contribute some day.

This post has been edited by Mark.: 29 October 2015 - 01:00 PM

1

Share this topic:


  • 212 Pages +
  • « First
  • 176
  • 177
  • 178
  • 179
  • 180
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options