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

Jump to content

  • 213 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   Hendricks266 

  • Weaponized Autism

  #5311

Lesson learned: Don't give your mod assets filenames that collide with the main game's music. If it's not Taking the Death Toll, don't name it dethtoll.mid.

dethtoll.mid being hardcoded is a long-standing problem on the to-do list, that will likely be augmented with def music "usermap" syntax like "intro"/"briefing"/"loading".
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5312

I believe it should be more appropriate to include a .def file with Eduke32 that lists files to be replaced, like grabbag.mid with grabbag.ogg. I don't see how it's a better option to have filenames hard-coded.
0

User is offline   Jblade 

#5313

View PostHendricks266, on 09 June 2015 - 10:32 AM, said:

Lesson learned: Don't give your mod assets filenames that collide with the main game's music. If it's not Taking the Death Toll, don't name it dethtoll.mid.

This was never a problem until Megaton edition compatability, so please don't try and tell me about lessons thank you :)

I figured this out and fixed it ages ago on my end, it was only presenting a problem with the guys who had Megaton installed (I didn't and didn't know that Eduke32 autoloads Megaton content)

This post has been edited by Jblade: 09 June 2015 - 01:43 PM

1

User is offline   Hendricks266 

  • Weaponized Autism

  #5314

View PostFox, on 09 June 2015 - 01:07 PM, said:

I believe it should be more appropriate to include a .def file with Eduke32 that lists files to be replaced, like grabbag.mid with grabbag.ogg. I don't see how it's a better option to have filenames hard-coded.

Nothing is hardcoded beyond adding the Megaton paths. The automatic "does an OGG or FLAC exist of this MIDI/VOC?" kicks in from there.

View PostJblade, on 09 June 2015 - 01:41 PM, said:

This was never a problem until Megaton edition compatability, so please don't try and tell me about lessons thank you :)

Contrarily, naming something in an inaccurate fashion is poor practice in general.
0

User is offline   Jblade 

#5315

There was nothing 'inaccurate' about the filenames, and it was never a problem until Megaton content started being autoloaded. It's your port so it's your choice to auto integrate the content, but I think that absolutely nothing should be loaded from Megaton at all by default. I don't bother keeping it installed because it intefers with Eduke regularly if I'm trying to play a TC or whatever.
1

User is offline   Micky C 

  • Honored Donor

#5316

Can there be some description added to the wiki for openGL's new fogpal feature? http://wiki.eduke32.com/wiki/Fogpal
0

User is offline   Daedolon 

  • Ancient Blood God

#5317

I was lazy but there you go.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5318

View PostMicky C, on 13 June 2015 - 04:05 PM, said:

Can there be some description added to the wiki for openGL's new fogpal feature? http://wiki.eduke32.com/wiki/Fogpal

http://wiki.eduke32....Language#fogpal

View PostDaedolon, on 14 June 2015 - 10:07 AM, said:

I was lazy but there you go.

:)

The standalone page should have a description of the member of the sector structure also named fogpal.
0

User is online   NightFright 

  • The Truth is in here

#5319

I see r5267 finally fixes the automap problem with Polymer. Thanks a lot, folks! ^^
0

User is offline   Paul B 

#5320

I was wondering why Eduke32 runs so much faster in an XP operating system as oppose to Windows 7? I have a system which can dual boot between Windows 7 64 Bit and Windows XP. Hands down my FPS are so much better in XP at least 20 fps faster running Polymer. Does anyone have any suggestions as to why this might be? This also isn't something new, this has always been the case for as long as I remember which is why when I map I still map using XP. Is there a way to optimize Eduke32 for Windows 7 so it can run just as efficiently?

This post has been edited by Paul B: 16 June 2015 - 08:22 AM

0

User is online   Danukem 

  • Duke Plus Developer

#5321

It has been a few years since I was up-to-date on eduke32 capabilities, so I need to ask about sound. Do we have true volume control over sounds using CON commands yet? Back in the day there was not -- you could adjust the volume parameter in the sound definition, but all it did was adjust a distance offset on the sound. Pretty useless if the sound is being played from the player.

EDIT: Wouldn't it be pretty simple to add an optional volume parameter to the sound command? It could be added to the sound's volume parameter in the definition for that particular instance. And yes, I know that I could simulate the same thing by spawning a sprite that plays the sound a certain distance from the player.

This post has been edited by Trooper Dan: 30 June 2015 - 01:33 PM

0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5322

No. And it probably will only be added when there is a better sound system (i.e. the volume option in the menu is a distance hack).
1

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5323

The clipdist showing in the editor is interesting. I suggest it to only show in sprites with a cstat of 1.
0

User is offline   Kyanos 

#5324

View PostPaul B, on 16 June 2015 - 08:21 AM, said:

I was wondering why Eduke32 runs so much faster in an XP operating system as oppose to Windows 7? I have a system which can dual boot between Windows 7 64 Bit and Windows XP. Hands down my FPS are so much better in XP at least 20 fps faster running Polymer. Does anyone have any suggestions as to why this might be? This also isn't something new, this has always been the case for as long as I remember which is why when I map I still map using XP. Is there a way to optimize Eduke32 for Windows 7 so it can run just as efficiently?


turn off aero
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5325

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

Posted Image

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

0

User is offline   Jblade 

#5326

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

#5327

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!

#5328

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

User is offline   Helixhorned 

  • EDuke32 Developer

#5329

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

#5330

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

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5331

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

#5332

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

  #5333

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 offline   LeoD 

  • Duke4.net topic/3513

#5334

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!

#5335

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 Developer

#5336

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!

#5337

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 Developer

#5338

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!

#5339

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 

#5340

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

Share this topic:


  • 213 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