[Micky C]

Someone needs to make a blade-runner inspired level for this. It'd need a lot of new textures though.

[Gambini]

I´ve just downloaded the latest eduke32 from the synthesis repository and installed this mod and i get all white-washed colors and a text that reads widescreen warning.

I´m playing in 1280x1024 in windowed mode, dont understand why it says that. Should i cover both remain sides of my screen with ducttape?

EDIT: Just fired a couple of the original maps, and the issues are gone (minus the widescreen warning, which doesnt go away even if i go fullscreen with correct pixel ratio). The HDR is kind of too intense, almost annoying. The only new features I found were the ballistic rocket for the RPG (which is awesome BTW), The flamethrower and the crossair ammunition (maybe too much stuff on the center of the screen?).

It´s all great but I think you definetely need a good map to introduce all this to players. The "test hypercore map" episode returned me to the menu and in the usermap list I only found raw test maps, most of which looked like the gamma went out of control.

[Hendricks266]

Gambini, on 14 October 2014 - 04:16 PM, said:

I´m playing in 1280x1024 in windowed mode,

1280x1024 is 5:4, not 4:3, and therefore shitty. Try something different.

[Jan Satcitananda]

Gambini, on 14 October 2014 - 04:16 PM, said:

I´ve just downloaded the latest eduke32 from the synthesis repository and installed this mod and i get all white-washed colors and a text that reads widescreen warning.

I´m playing in 1280x1024 in windowed mode, dont understand why it says that. Should i cover both remain sides of my screen with ducttape?

EDIT: Just fired a couple of the original maps, and the issues are gone (minus the widescreen warning, which doesnt go away even if i go fullscreen with correct pixel ratio). The HDR is kind of too intense, almost annoying. The only new features I found were the ballistic rocket for the RPG (which is awesome BTW), The flamethrower and the crossair ammunition (maybe too much stuff on the center of the screen?).

It´s all great but I think you definetely need a good map to introduce all this to players. The "test hypercore map" episode returned me to the menu and in the usermap list I only found raw test maps, most of which looked like the gamma went out of control.

Yup, the mod has a duct tape detection algorithm and will not work until your screen is sufficiently covered =P
JK, lol. Try 1280x960 fullscreen if your rig can handle it. As Hendricks noted, 1280x1024 is 5:4 and unsupported. Later I might add a support for square screen modes (like 640x640), which are more suitable for Build games because of wider vertical angles. Thus, I'm kinda going in opposite direction than mainstream gaming industry which has increased horizontal angles instead.

Dunno about the washed out colors, maybe check the color correction menu. I've increased shading contrast in the original level preprocessor a bit (in order to test HDR lighting in various conditions), but you may alter the way it looks. There's an AMBIENT_SHADE_GAMMA variable in LNGAINIT.CON which is initialized with a value of 640; if you change it to 256 or so, the lighting will look more like in the original game.

The hypermap is supposed to be a map composed of multiple smaller maps which can be dynamically loaded and unloaded as you visit different parts of the map (thus, hypermaps can have extreme complexity totaling over a million sectors); I hope to get it to work in the next release. Also you'll see the crosshairs fully animated and working with the new weapons (which they are intended for). Thx for the feedback.

[zykov eddy]

I think this mod pretty much proved that nothing is impossible, at least in the world of Build Engine. The coding is very high class and the effects are stunning, I especially like the mirror walls effect. CraigFatman, why aren't you working for a major IT company yet?

[Jan Satcitananda]

zykov eddy, on 19 October 2014 - 05:07 AM, said:

I think this mod pretty much proved that nothing is impossible, at least in the world of Build Engine. The coding is very high class and the effects are stunning, I especially like the mirror walls effect. CraigFatman, why aren't you working for a major IT company yet?

There are always limitations, and the more you dig into the engine mechanics, the more of them do emerge; it's mandatory though to know about them in order to find ways to defy them.

I'm working for Motorola Solutions atm, although I see myself mostly useless in jobs. The demands of IT industry and the things I'm really interested in are way too different things.

[Jan Satcitananda]

Currently working on the map editing "gadget" which (theoretically) enables users to make maps and test them at the same time, making the process of mapping a lot easier, especially with stuff like HDR and multiple palettes. It's only a starting point though; just brought in some GUI element placeholders and two info panes (like in Mapster). Note that the 3D view is constantly enabled, but darkens a bit when the 2D map is overlaid (kind of a hybrid 2D/3D mode). The grid is the latest addition. Btw, to load the tile names, my CON script reparses itself during the game (I've moved all the tile definitions to a separate con file to speed it up).



One can toggle the 2D map view, as well as lock/unlock the mouse pointer. Nothing is interactive so far, but someday it will turn Duke into a sandbox game. =D
Also I'm going to draw (overlay) object outlines in 3D so user could clearly see the boundaries of current object. Speaking of usability, maybe something else can be done to this?

[Player Lin]

I'm speechless...

[Micky C]

Very interesting. TX or someone has always been saying it should be more or less possible to code a map editor into eduke, but I didn't think anyone was going to do it.

Can it do more or less everything mapster can do? If so, do you think there'll be a version for vanilla Duke?

[Fox]

I think it's not very optimal to make a 2D map with sprites. It would be great if Eduke had an option for vectors.

[Jan Satcitananda]

Micky C, on 24 October 2014 - 06:44 PM, said:

Very interesting. TX or someone has always been saying it should be more or less possible to code a map editor into eduke, but I didn't think anyone was going to do it.

Can it do more or less everything mapster can do? If so, do you think there'll be a version for vanilla Duke?

It's an imprortant advantage of Build engine (being a raycast engine) that the map can be changed on the fly, including the topology (the way walls are connected to each other). It's a shame that Build games didn't make use of dynamic topology during the game for some awesome effects. We could explode any walls and make holes just everywhere and be able to destroy any structure, not just the places set by the level designer. Not to mention 3D boolean operations over sectors... some of these possibilities might be too tough for CON coding though, still LNGA maps will be a lot more dynamic than vanilla Duke levels.

EDuke32 only has a little problem creating new sectors. As the variables storing the number of sectors and walls are read-only, one has to load a map which already contains 4096 sectors and 16384 walls in a 'hidden' state, and then 'reveal' them on demand.

The internal logic of LNGAG3D editor should be mostly applicable for conventional map editing, since map formats are the same. One would have to rewrite the user interface from scratch though.

Fox, on 24 October 2014 - 06:50 PM, said:

I think it's not very optimal to make a 2D map with sprites. It would be great if Eduke had an option for vectors.

What kind of 'vectors' are you talking about? Seeing sprites in 2D mode is very helpful, isn't it?

[Fox]

I meant to make the lines.

[Jan Satcitananda]

Oh, I've got it; lines I'm currently displaying on the screen consist of a series of dashes few pixels long, and the remainder is filled point by point (drawing entire line point by point was very slow). Both dashes and point use linear gradients to attain anti-aliasing effect (kinda fake bilinear filtering). Build engine doesn't seem to have specific line drawing functions...

[Micky C]

CraigFatman, on 25 October 2014 - 12:16 AM, said:

It's an imprortant advantage of Build engine (being a raycast engine) that the map can be changed on the fly, including the topology (the way walls are connected to each other). It's a shame that Build games didn't make use of dynamic topology during the game for some awesome effects. We could explode any walls and make holes just everywhere and be able to destroy any structure, not just the places set by the level designer. Not to mention 3D boolean operations over sectors... some of these possibilities might be too tough for CON coding though, still LNGA maps will be a lot more dynamic than vanilla Duke levels.

That certainly sounds exciting. Hopefully by the time you're ready to make maps, some of these features may be possible or otherwise easier to do, perhaps with the lunatic builds.

[MetHy]

CraigFatman, on 25 October 2014 - 12:16 AM, said:

It's an imprortant advantage of Build engine (being a raycast engine) that the map can be changed on the fly, including the topology (the way walls are connected to each other). It's a shame that Build games didn't make use of dynamic topology during the game for some awesome effects. We could explode any walls and make holes just everywhere and be able to destroy any structure, not just the places set by the level designer. Not to mention 3D boolean operations over sectors... some of these possibilities might be too tough for CON coding though, still LNGA maps will be a lot more dynamic than vanilla Duke levels.

I haven't tried it myself but Shadow Warrior has an effect with which walls can be deleted in game, though again, only when defined by the mapper.

[Micky C]

Walls deleted? What do you mean?

[MetHy]

I can't seem to find it anymore, but I'm sure I've read about an effect which would delete walls: it doesn't actually delete the wall, but the vertice (think of it as if you're in Build and you drag a vertice to the next one, which deletes the wall).
Maybe I'm confusing with something else or another game though because I can't seem to find it anymore...

There is also the possibility to delete sectors (hitag80: so_killable); but again that is only when pre-defined by the mapper (and of course there is always the 'copy sector' effect in SW which you can use to pretend this kind of destroyable environments, but again only defined by the mapper).

[Jan Satcitananda]

Afaik, sectors were 'deleted' there just by setting their properties (texture and altitude) to those of a neighbor sector (dunno about walls). Maybe I'm wrong, didn't actually check how it works.

The mod now has a page on ModDB =P
http://www.moddb.com...rt-qwnz0r-qnw3d

Stay tuned for a video of ingame map editing...

[Helixhorned]

Gambini, on 28 September 2014 - 01:08 AM, said:

I think the lack of replies comes from the complex nature of your writtings.

That's certainly true for me. Besides the complexity of the matter, the effects touch many aspects so that it's hard to compose a proper essay. And stuff for a few essays there is.
----------

@Lezing: I have recently looked into the multipass rendering code in LNGA3. I find it impressive that using one system, you achieve such a variety of effects. The one that caught my attention for the purpose of this post is wall-over-wall rendering. For reference, this is what I mean:

*

I was pleasantly surprised to see that in the first screenshot, the lower sector is at its actual x/y place! My understanding here is that you basically employ 1:N redwalls (i.e. what gets labeled "already-referenced corruption" in Mapster32 unless corruptcheck_noalreadyrefd is enabled), and from the "1" side, help the engine by drawing the portion leading into the "auxiliary" sector(s) yourself, by appropriately issuing showviewunbiased. A nice side-effect of this is that sprites are drawn properly. In the second screenshot, the upper portion is in a distinct location though.

The reason I'm bringing this up is because the functionality currently missing in the first case -- firing projectiles and moving underneath the "bridge" -- could be implemented in the EDuke32 engine. As a prerequisite, it would only need to "know" about 1:N redwalls. Then, clipmove() and hitscan() could be extended accordingly. The usual detail questions would need to be addressed^[1], but conceptually it's easy. As a next step, I'm even thinking of making the classic renderer issue additional passes from the "1" side itself, which is more involved though. All in all, WoW is great because it nicely complements (T)ROR: you don't need a separating horizontal plane.

^[1]For example, should we add a new wall cstat bit to signal new functionality, or make 1:N redwall detection automatical, potentially risking clashes with earlier uses?

[Micky C]

I've been waiting for 1:N redwalls all my life

Once that's in as an official eduke feature, the difference between a duke map and a 3D map from some other game would be greatly reduced. Local TROR would greatly facilitate 3D geometry in outdoor spaces or otherwise where 1:N sectors is inappropriate or cumbersome, and things like true 3D elevators, with windows in the walls as you go up would be doable.

[Jan Satcitananda]

Helixhorned, on 04 January 2015 - 01:13 PM, said:

@Lezing: I have recently looked into the multipass rendering code in LNGA3. I find it impressive that using one system, you achieve such a variety of effects. The one that caught my attention for the purpose of this post is wall-over-wall rendering. For reference, this is what I mean:

The staged rendering system has a lot of planned features indeed, including varying exposure/color and mirroring the map for certain passes, but most of them might never work to the full due to performance problems and other factors. So far it can be used for dynamic skyboxes, viewing through floors/ceilings and simple wall-over-wall constructions. I tried to build a fully 3D electric train carriage but I've faced certain rendering problems which I'm currently working out.

Helixhorned, on 04 January 2015 - 01:13 PM, said:

The reason I'm bringing this up is because the functionality currently missing in the first case -- firing projectiles and moving underneath the "bridge" -- could be implemented in the EDuke32 engine. As a prerequisite, it would only need to "know" about 1:N redwalls. Then, clipmove() and hitscan() could be extended accordingly. The usual detail questions would need to be addressed^[1], but conceptually it's easy. As a next step, I'm even thinking of making the classic renderer issue additional passes from the "1" side itself, which is more involved though. All in all, WoW is great because it nicely complements (T)ROR: you don't need a separating horizontal plane.

^[1]For example, should we add a new wall cstat bit to signal new functionality, or make 1:N redwall detection automatical, potentially risking clashes with earlier uses?

I don't think it's really that easy. The walls in Build have only a single 'nextwall' parameter, and one would need to store a list of such walls for so-called 1:N walls, Would you employ parameters like 'prevnextwall' and 'nextnextwall' for this? =D

Of course, additional wall connections might not be stored on disk and found automatically on map load (and placed into a separate array), but this would cause compatibility problems and increase loading times considerably.

Actually I'm going to use 'multi-pass' hitscan extension routine which automatically continues the hitscan in a new sector if the ray has bumped into a 'voidtile' (a portal to some WoW structure). Also I need more accurate collision detection, so I might do all the required math for clipping in CONs.

Of course, if you want to add some kind of wall-over-wall support to TROR, you'll need to find a way to implement the new functionality in the engine. It would be great to have such feature in conventional Duke maps.

My future game engine (based on the same principles as Build engine, but takes it a little further), will use separate arrays for 'walls' and 'wall ranges', and each individual wall will be treated as a set of independent ranges stacked on top of each other. Each range is basically a trapezoid-shaped section which can possess a texture or have a portal to another sector (possibly masked with a texture). In Build, however, we're practically restricted to a single 'range' per wall.

[Jan Satcitananda]

After a fresh glance, I've cancelled the project. We have enough great TCs nowadays. This mod is just way too ambitious and doesn't seem to be possible in Duke.

[RichardStorm]

April Fish ? XD

In case what you say is true, forgot it. A TC like this with all its non-conventional massive CON features is absolutely unique.

[DavoX]

I hope you were kidding man

[Fox]

CraigFatman, on 01 April 2015 - 10:44 AM, said:

After a fresh glance, I've cancelled the project. We have enough great TCs nowadays. This mod is just way too ambitious and doesn't seem to be possible in Duke.

[Jan Satcitananda]

DavoX, on 03 April 2015 - 01:45 PM, said:

I hope you were kidding man

Shizzle, lol. There's no way to renounce the amount of work already put into this. So as I pray, Unlimited Duke Works! =P



The point I'm currently stuck in is the built-in map editor described some posts above. I've already outlined the tile browser, the palette selector and the multi-selection feature, so things are easy; still it will take some time to get it to work. Then I'm going to add support for editing map geometry.

[DavoX]

Is it going to be easier than lebuild?

[Jan Satcitananda]

How are you guys? =)
Recently I've finally come back to this project and made some progress on the built-in editor GUI, namely the palette library and the tile browser, both featured on the screenshots below. Still it will take some days for the latter to gain the full functionality.





Things keep changing in a number of ways for me lately, which marks that I'm proceeding to a new phase of life, so now it's time to select another nickname as well. Merry Christmas to all btw! I think I'll be able to showcase a new version of the mod (v0.4) in the upcoming year.

DavoX, on 08 April 2015 - 02:42 PM, said:

Is it going to be easier than lebuild?

Definitely it's going to be more visual and having a lot more what-you-see-is-what-you-get feel. It might not have features like scripting and working with complex geometry, but the available functions are expected to be more organized and refined as compared to LEBuild's feature set. For instance, now you'll be able to work with all kinds of objects at the same time (sectors, walls & sprites), or use the pre-lighting system and other stuff integrated with the game.

[Danukem]

You do amazing work at a technical level that I cannot approach. Are you using mapster script to build the GUI? This could become the standard for Duke mappers. But what if they don't want to use CLUT, or they have their own palettes?

[Micky C]

Trooper Dan, on 25 December 2015 - 11:54 AM, said:

Are you using mapster script to build the GUI?

He's building the editor within eduke32 IIRC. It'll be interesting to see in what capacity it'll be able to replace mapster32. IMO a big strength of a built-in editor like this would be able to quickly test things then reset back to the original quickly, although you can sort of do that within mapster with the test option which boots straight into the map in eduke.