[XThX2]

DeeperThought has filled the blank spot of weapon workslike, you can read it to see what it does. (Pretty useless, IMO)

[Danukem]

XThX2, on Jul 28 2009, 06:19 AM, said:

* Request *

A command or variable to turn off the hardcoded behaviour of specific weapons, mainly pipebombs and tripbombs. Is this possible? (I tried to code my own weapon as a replacement of tripbombs, but there are too many annoying bugs which I have no idea how to fix)

When I started this thread it was supposed to be about Polymer, but it seems like it's becoming the random shit thread.

The wiki entry I wrote about weaponx_workslike is not entirely accurate. For example, if you change the workslike of weapon 8 to 2, it will "fire" even if away from a wall (so it doesn't just change the appearance). You can make any weapon slot do anything you want by changing the weaponx variables and adding your own code to processinput or the player actor or wherever is appropriate.

If you think about it, your request is almost meaningless. All the weapon behavior (the actors spawned by them are another story) is hardcoded, and what EDuke32 allows us to do is override that hardcoded behavior. If you want to "turn off" the hardcoded behavior of a weapon, all you have to do is prevent it from firing by canceling EVENT_FIRE or setting kickback_pic to 0, and then code your own weapon that doesn't use the hardcoded system.

[mydsic4]

Pretty cool demo. But, one question: why?

Why shoehorn all this technology in an old engine? I'm not playing Duke to make my eyes bleed with the ecstasy of modern graphics. If you want better lighting, why not create some Duke mods for the Quake series' engines? Seems to kind of cheese up the original experience and introduce more performance overhead (and bugs).

There's always a push to "modernize" old games and bring them "into the 21st century!!!" I don't want to sound like an old fart, but sometimes I wish "21st century" games would act a little more 20th century, because it's all graphics achievement and 0% gameplay. I'd rather see new levels than dynamic lighting. That, or I'd rather see some sweet Duke mods made inside other engines -- maybe it would be more fun and productive?

[Sangman]

What's with the black and white vision of "Either it has 'bad' graphics or it has shitty gameplay"?

This is not about "bringing it into the 21st century!!!" but to give mappers more possibilities to make good looking stuff. A casual gamer like what you seem to come across as might not grasp that but anyone else would tell you dynamic lighting as opposed to manual sector lighting is a good thing. The only problem with it in Eduke32 is that apparently the dynamic lighting requires quite a strong machine.

[LeoD]

mydsic4, on Jul 28 2009, 09:41 PM, said:

Pretty cool demo. But, one question: why?

Why shoehorn all this technology in an old engine?

The answer should be obvious : because it's fun for those who do it.

Unlike many community driven projects all this eduke32/HRP/DukePlus stuff is done for the fun of it, not for kudos or a better world.

mydsic4, on Jul 28 2009, 09:41 PM, said:

There's always a push to "modernize" old games and bring them "into the 21st century!!!" I don't want to sound like an old fart, but sometimes I wish "21st century" games would act a little more 20th century, because it's all graphics achievement and 0% gameplay. I'd rather see new levels than dynamic lighting. That, or I'd rather see some sweet Duke mods made inside other engines -- maybe it would be more fun and productive?

Being an old fart myself (older than most of the forum members for sure) I really appreciate all those efforts that keep my Duke experience alive and evolving. I'm no die-hard old school gamer because I prefer the HRP - but most newer games lack this special comic style atmosphere and gameplay. Since the DPCBP update I even plan on buying a new graphics card to play it with polymer at acceptable framerates. :-)

While I'd prefer to see more new maps, too, I can understand that it might be more fun to create and code cool things like Naferia's Reign or Sonic3D although those will attract way fewer players than a good new map I suppose.

[atlas]

is it possible to use eduke to play shadow warrior?

[LeoD]

No. Get SWP.exe from http://www.proasm.com
There's a high resolution pack also.

[TerminX]

mydsic4, on Jul 28 2009, 01:41 PM, said:

Why shoehorn all this technology in an old engine? I'm not playing Duke to make my eyes bleed with the ecstasy of modern graphics. If you want better lighting, why not create some Duke mods for the Quake series' engines? Seems to kind of cheese up the original experience and introduce more performance overhead (and bugs).

Because we want to work on and mess with Duke source ports, not make some cheesy Quake mod. EDuke32 exists to allow everyone who wants to enjoy good old Duke3D to do so, and also to create a free platform for people to fairly easily create their own custom games quickly and easily with sweet results.

Quote

There's always a push to "modernize" old games and bring them "into the 21st century!!!" I don't want to sound like an old fart, but sometimes I wish "21st century" games would act a little more 20th century, because it's all graphics achievement and 0% gameplay. I'd rather see new levels than dynamic lighting. That, or I'd rather see some sweet Duke mods made inside other engines -- maybe it would be more fun and productive?

Your statements are pretty contradictory. We just wanna allow dedicated fans and new followers to do more with Duke than they ever could before. I'm not sure why you'd prefer the imitation (Duke brought to another engine as a mod) over the real thing (a modern engine brought to Duke).

So, back on topic... anyone still having trouble compiling current svn with MinGW?

[Lord Misfit]

LeoD, on Jul 28 2009, 05:20 PM, said:

While I'd prefer to see more new maps, too, I can understand that it might be more fun to create and code cool things like Naferia's Reign or Sonic3D although those will attract way fewer players than a good new map I suppose.

XD! On that note, NR will have it's own [unique] maps eventually, and I can't say I'd know about Sonic3D since that's not my mod. But it's nice to know there's another person I don't know well. who cares some about my dinky old mod.

But in some seriousness to who was talking about modding Duke in Quake or something like that, there's also the issue of legality. People have come here talking about Duke mods for Half-Life and a few other non-BUILD engine games, and they are generally not received too well here because 3DR tends to get moody with people who use the Duke license in another engine [despite currently not having a development team, it's still a legal entity and they can give you trouble for it]. This is another reason EDuke32 is good to have with all the updates to both coding and graphics.

While I'll admit I don't play EDuke32 for the HRP/Polymost/Polymer right now [half due to my crappy computer and lack of income to upgrade], it's coding system is what I perfer, as I am a modder and to a degree a mapper by heart. Look at it like this. You don't HAVE to use the extra graphics engines just to play EDuke32. Those can be left off and you can stay in 8-bit mode. Although... not all people can be pleased I guess. o.o

EDIT: Oh, and sorry to knock off topic there TX, so I'll agree and say we should get back on the real topic here now.

[Gambini]

The Commander, on Jul 24 2009, 10:37 PM, said:

Also works for Tek War if you change the palette's of course.

I never noticed this before, or maybe because it´s new. Tryed all the build games i know of and all them worked TekWar, Witchaven, Fate, PowerSlave, Lameduke (didnt try Blood either SW). It´s pretty cool how the colours theme change according to the map version and you can see a short message ¨map version 3´ sort of. This is easily one of the best features i found in mapster3d, and i´m sure it also can save the map keeping the orignal format (right?). Another feature i would add is recognizing .dat files or other .grp files when you press F in the load map menu.

EDIT: Tekwar for some reason had a mess with the colours in 3d mode, this is weird because the folder includes the pallete.dat.

[Sobek]

Hmm, can you apply normal maps to multiple animated tiles that use the 'animtilerange' command? All the log shows is "Error on highres/textures.def line xxxx" for each line of the animtilerange. I initially tried creating a normal map for each frame and simply inserting it in the DEF below each texture, just as you would on any other, but that didn't work. I then tried creating just one normal map and inserting it at the end of the list of tiles in the animtilerange, but it failed all the same.

I noticed that with the HRP water texture, each frame is defined seperately, which is fine as it's only 3 frames. But my animations (some walls with flashing red alert stuff, and my own water animation) are often 10-20 frames in length, making it far more simple and easy to use animtilerange and dummytilerange to define them. I tried creating my own water normal map and applying it to the HRP water and it worked fine, so I know it's not an issue with my normal maps... All I can guess is that something about the animtilerange command is making it ignore normals, or just consider their def lines as erroneous.

*edit* Here is an example of the defs for my water animation;

dummytilerange 9948 9963 52 52
texture 9948 { pal 0 { file "highres/textures/water/1.png" } nocompress }
   normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 }
texture 9949 { pal 0 { file "highres/textures/water/2.png" } nocompress }
   normal { file "highres/textures/water/2n.png" parallaxbias 0.3 parallaxscale 0.3 }
**and so on down to tile 16, number 9963**

animtilerange 9948 9963 3 2
}

I then tried;

dummytilerange 9948 9963 52 52
texture 9948 { pal 0 { file "highres/textures/water/1.png" } nocompress }
**tiles 2 - 15**
texture 9963 { pal 0 { file "highres/textures/water/16.png" } nocompress }

animtilerange 9948 9963 3 2
   normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 }
}

On that last code, I also tried moving the normal file ABOVE the animtilerange command, so it was directly below the last tile number, 9963 - still no go. Admittedly with this last bit of code I was just reaching and trying ANYTHING to make it work.

I hope I've just missed something stupidly obvious here...

[Fox]

I don't understand what you did. I use animtilerange as an lonely command, not inside an specific { }. That isn't supposed to work, is it? =/

[Sobek]

Seems to work fine for me...

Basically I first define all the frames of the textures I want using DUMMYTILERANGE. Then, immediately after that, I throw my ANIMTILERANGE in to animate the previously defined tiles, exactly as shown in the code there.

Other than these issues getting normal maps to work on the animated tiles, I have no other problems, and the animations play just fine. I don't know if that's any easier to understand

[Plagman]

Sobek, on Jul 29 2009, 06:01 AM, said:

I initially tried creating a normal map for each frame and simply inserting it in the DEF below each texture, just as you would on any other, but that didn't work.

 texture 9948 { pal 0 { file "highres/textures/water/1.png" } nocompress }
	normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 }

You can't do that. You define the normal map as you would with any alternate pal. How is the DEF code supposed to know to which texture the normal map applies with your code? Do:

 texture 9948 {
  pal 0 { file "highres/textures/water/1.png" nocompress }
  normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 }
}

Please also note how I moved nocompress to where it belongs. To answer your initial question, you can't define a normal map with animtilerange like what you were trying to do.

[Stabs]

TX, on Jul 28 2009, 03:26 PM, said:

So, back on topic... anyone still having trouble compiling current svn with MinGW?

i can get 1476 working (the earlier ones wouldnt compile), classic mode only, HRP or dukeplus have no sound & causes it to freeze after you select episode and difficulty

i tried clearing cache and cfgs as a solution but no luck

[Piterplus]

TX, on Jul 29 2009, 03:26 AM, said:

So, back on topic... anyone still having trouble compiling current svn with MinGW?

1476 compiled OK (MinGW gcc-4.3.3), no issues with sound , or Polymer mode.
Although there was some warnings while compiling.
Here is the log:

Attached File(s)

•  log.txt (6.99K)
  Number of downloads: 1246

[supergoofy]

all bugs reports for eduke32 svn builds should reported here:
http://forums.duke4....?showtopic=1180

[Piterplus]

I know that, but it was not a bug report, it was answer to TerminX's direct question.

[supergoofy]

most of the warnings are defined parameters that are not used. this is of no importance.

[Sobek]

Thanks Plagman, you learn something new every day

[themaniacboy]

Can i play this on a Sapphire 4770 HD ?

[Stabs]

wow just fucking wow, its not solid but damn when it is


and people just thought polymer was pretty lights

[TerminX]

DanM, on Jul 29 2009, 07:16 AM, said:

and people just thought polymer was pretty lights

Nope, Polymer is a completely new system of dynamically generating static 3d architecture based on "2.5d" map data. A lot of stuff that would give you the "hall of mirrors" in classic or Polymost will just work in Polymer, simply based on how it operates.

[Sangman]

Okay wow. I didn't know about that, so
mind = blown

[Mark]

and people just thought polymer was pretty lights

And I have been doing that effect and ROR all over the place in my map with half a million sprites painfully sized and aligned. At least it will be easier next time around with polymer.

[Gambini]

TX, on Jul 29 2009, 04:16 PM, said:

Nope, Polymer is a completely new system of dynamically generating static 3d architecture based on "2.5d" map data. A lot of stuff that would give you the "hall of mirrors" in classic or Polymost will just work in Polymer, simply based on how it operates.

Is not polymost also a ¨system of dynamically generating static 3d architecture based on "2.5d" map data¨? That´s what i always thought at least


(yeah, i know that what Damn did is not possible in polymost)

[TerminX]

The difference is that Polymost tessellates only what you can see, on the fly, every time you draw a frame (e.g non-static 3d geometry), whereas Polymer maintains an actual 3D representation of the 2.5D map in memory at all times.

[Gambini]

I see, really interesting. Then Polymer seems to be more smart-designed in performancewise. I guess that with time, when it gets finally released, and properly optimized will be less demanding than polymost (lights apart).

How hard would be making an optional 8bits filter in order to turn all the awesomeness of polymer into the 8bits looking?

[Stabs]

Marked, on Jul 29 2009, 04:58 PM, said:

and people just thought polymer was pretty lights

And I have been doing that effect and ROR all over the place in my map with half a million sprites painfully sized and aligned. At least it will be easier next time around with polymer.

ahh the old sprite floor, i dont think i'll miss you

my #1 gripe with them was how lighting affected them, they could look so out of place at times, used to have an airvent running along the roof of the cinema foyer in TTA2 but i had to drop that because of how lighting affected it.

I like the sound of what gambini said, it could actually run nicer than polymost, mmmm big open levels could be back on the menu.

[Sangman]

Gambini, on Jul 30 2009, 04:07 AM, said:

How hard would be making an optional 8bits filter in order to turn all the awesomeness of polymer into the 8bits looking?

Hm? You can run - so they say - Polymer using the old 8bit textures so I don't know what you mean.