LNGA mod & Qwnz0r Qwn3d TC "A real geeky total conversion in progress"
#91 Posted 26 June 2010 - 10:19 AM
#92 Posted 26 June 2010 - 01:49 PM
Helixhorned, on Jun 26 2010, 10:19 PM, said:
The mod offers a controller system based on Euler ODE solvers, designed to control map effects and actor dynamics. The player dynamics like the radar/crosshair rotation are evaluated by ODE solvers as well.
Each actor stores its XYZ velocities, high-resolution angle value and Z angular speed as separate per-actor variables to maximize precision of calculations. I'm planning to evaluate motion as simplified rigid body dynamics with gravity, friction, normal force, air resistance and other forces acting. Any constraints (perhaps, by means of kind of "sprite-effectors") may be applied to form complex interactive sprite systems. Limited support of soft bodies, aerodynamics or even fluids is also expected.
I've already done a prototype of a sector controller, but I need to refine it with more precise algorithms, as well as more usable controller schemes (making separate sprites for each force may be too complicated at times, especially for various doors).
In conventional Duke3D, for example, you set a lotag 23 to a sector and put a SE 11 into it to make a swing door. Your door opens and closes at a specified angular velocity, undergoing infinite acceleration. In LNGA, a sector rotation controller (having a moment of inertia) gets instead of the SE 11 and then should be connected to a set of force, drag and limit sprites which will handle door's motion. Also, I'll add a sector motion controller for things like sector boxes able to move on the floor and collide with each other in a realistic way.
This post has been edited by CraigFatman: 26 June 2010 - 01:52 PM
#93 Posted 26 June 2010 - 03:28 PM
CraigFatman, on Jun 26 2010, 11:49 PM, said:
I'm speechless.
#94 Posted 25 September 2010 - 09:25 AM
The skybox reflection in blocks on the floor is prerendered into separate tiles to simulate Fresnel falloff.
One can view any pass of the collection separately using the CPC debug tool.
Unfortunately, this showview-based system does not work correctly on a tilted screen. I've reported about it in this thread: http://forums.duke4....?showtopic=2799
This post has been edited by CraigFatman: 07 September 2014 - 09:38 AM
#95 Posted 25 September 2010 - 03:28 PM
#96 Posted 25 September 2010 - 03:56 PM
Captain Awesome, on Sep 25 2010, 04:28 PM, said:
Shit, sometimes I feel the same way when I look at this thread.
#98 Posted 25 September 2010 - 11:13 PM
The Commander, on Sep 26 2010, 09:00 AM, said:
It's not a problem to take higher-resolution screenshots, but 640x480 is usually sufficient. I'll try to use 1280x960 next time. However the HUD is displayed constantly and might distract too much. So I'm going to make a HUD retraction function binded to "+" key by default.
#101 Posted 26 September 2010 - 06:51 PM
def be using this to run final checks on maps and working with complex SoS stuff, how you can turn of sprites and select what you want to work with is good, probably wont use this as my main editor but ill be playing around with it on the side, needs some good tutorials on the RoR effects.
#102 Posted 26 September 2010 - 08:37 PM
The Commander, on Sep 26 2010, 09:47 PM, said:
JK
So, 640x480 resolution is still a friggin' heck of pixels compared to one Duke has come with...
JK
#103 Posted 26 September 2010 - 09:08 PM
lebuild could use some DXF or EPS importing, now that would be amusing
#104 Posted 27 September 2010 - 03:41 AM
DanM, on Sep 27 2010, 09:08 AM, said:
I agree; and exporting might be useful too 'cause I used to utilize LEBuild in creating simple vector shapes. I've designed the crosshairs for the LNGA mod in it, but I'm forced to use the "Printable scheme generator" feature to rasterize them in hi-res and then edit with Paint Shop Pro.
That's how I do:
Note: later I had moved each element of the crosshair into separate tiles to make possible changing the color and brightness of distinct parts independently.
This post has been edited by CraigFatman: 27 September 2010 - 03:49 AM
#105 Posted 27 September 2010 - 02:17 PM
Edit 20150218: updated URL.
#106 Posted 27 September 2010 - 02:26 PM
#107 Posted 28 September 2010 - 02:45 AM
Helixhorned, on Sep 28 2010, 02:17 AM, said:
Thanks for the importers, I'll try them when I install MATLAB.
[Edit by Helixhorned 2015-02-18: update URL in quote.]
#108 Posted 29 September 2010 - 10:47 AM
if (all(map.wall.picnum(b:e)==0) && ~any(map.sprite.sectnum==sec) && ... map.sector.floorpicnum(sec)==0 && map.sector.ceilingpicnum(sec)==0) continue end
This post has been edited by CraigFatman: 29 September 2010 - 10:48 AM
#109 Posted 24 February 2011 - 12:06 PM
My method to determine ambient light color and intensity at a given point inside a sector is far more sophisticated than just taking floor's shade and palette number. It features gradual transition from floor to ceiling color as the point moves along the sector. Here is a couple of screenshots with a comparison between intrinsic colors only and when ambient light is taken into account. As you can see, the mouse pointer sprites tinted with blue preserve their blue look under different light conditions. And the Mortar sprites which use Duke3D palette (not the IDX8_L that is native to my mod) get processed as well.
Everything said above is right for conventional Duke3D maps. A modder who makes LNGA-specific maps can take advantage of this as well, but should be able to disable ambient light at all when necessary and instead use pals and shades to change intrinsic colors of all surfaces freely. That is, my mod differentiates object's apparent shade and pal (caused by lighting) and its intrinsic reflectivity properties. This is crucial for CON-coded dynamic lights which aren't complete yet.
Another feature is about how the player is informed about being hit by enemies. Instead of "palfrom" commands which temporarily tint the whole screen, I've coded four bars put along the screen edges which blink with red when Duke is hit by something, showing where the damage comes from and how severe it is. The same bars blink with green when something is picked up.
I'm also remaking the lens flare code. There's already a support of different lenses, such as human eye, conventional video camera, CMOS camera or professional photo lens. Recently I've coded the lightning bolts to produce chains of flares. So far it has some problems, since the lightning sprite and its flares don't appear simultaneously, and one can't see any flares placed above the parallaxed ceiling.
This post has been edited by CraigFatman: 24 February 2011 - 02:49 PM
#110 Posted 24 February 2011 - 12:28 PM
CraigFatman, on Sep 29 2010, 07:47 PM, said:
if (all(map.wall.picnum(b:e)==0) && ~any(map.sprite.sectnum==sec) && ... map.sector.floorpicnum(sec)==0 && map.sector.ceilingpicnum(sec)==0) continue end
The point is to get rid of the "author name sectors" at the borders of the map so that they don't make the rest appear in a tiny portion of the axes. Nobody should use picnum 0 anyway .
#111 Posted 24 February 2011 - 01:28 PM
#112 Posted 24 February 2011 - 03:38 PM
#114 Posted 26 February 2011 - 06:41 PM
Gambini, on Feb 25 2011, 02:38 AM, said:
This would be complicated indeed. All the original Duke palettes are treated by the lighting system as white except pals #1, #2, #7 and #8. There's only partial support of those palettes. But since I'm using my own palettes to light things up with different colors (they look similar to hi-res texture tinting), this shouldn't be an issue. Eventually I'll replace some of alternate palettes used by monsters, keycards and other stuff with multi-layer sprites (when you see another transparent sprite just in front of the actor). The ultimate goal here is to have a variety of colors for keycards and access locks chosen randomly everytime a level begins (see http://img38.imagesh.../sandwichc.png/ to make out how does it work), as well as to make monsters with alternate pals shade correctly in colored sectors. Random color selection is one of the factors affecting replayability.
I'm working on the custom bonus screen, somewhat inspired by X-COM: UFO Defense, particularly the way it shows the level summary. It's a part of the integrated GUI, so the hard-coded bonus screen was deprecated. There are some additional statistics planned. Unfortunately, no access to Par/3D Realms times via CONs. The GUI widgets (such as windows and buttons) get displayed, but still don't process any mouse clicks, so one needs to hit Tab key to close the window and proceed to the next level. By the way, I've drawn those widgets to use them in my future applications, but since I've took a break at C++ programming, I'm using them in my mod too. Get ready to new videos as well.
A few words regarding the gameplay concept (I haven't begun anything so far). Duke3D enemies often use weapons which Duke can't domain (such as firelaser, mortar or mental blast), but I want to introduce a more precise inventory system. Specifically, to force each monster to have a limited amount of ammo and always drop everything it has (including the weapon) after dying, so Duke could pick it up. But most things dropped by enemies will require some research before being used, as initially they will be just unknown alien artefacts (again, like in X-COM). Research of an artefact can make it useful for player or give a technology for producing other objects on the factories (say, research Trooper's Firelaser weapon and manufacture Soliton Gun). As an alternative to sending things to the laboratory for research, Duke can search levels for "manuals" - files with information about an artefact that makes it usable as well. However, there's no access to laboratories and factories in 3D Realms episodes, thus the gameplay will be alike vanilla Duke there.
#115 Posted 27 February 2011 - 03:56 AM
CraigFatman, on Feb 24 2011, 12:06 PM, said:
Doooo waaaahhhnntsss!
#117 Posted 27 February 2011 - 04:37 AM
#118 Posted 27 February 2011 - 04:40 AM
Is there going to be a base-style map in the mod, or is it gonna be one long adventure like normal Duke?
#119 Posted 27 February 2011 - 06:04 AM
Quote
What? Isn´t that one of the easiest things to change in duke? just take a look to user.con or defs.con i think. There´s the map listings per episode and each one has its name next to the 3d realms time!
#120 Posted 27 February 2011 - 07:05 AM
James, on Feb 27 2011, 03:40 PM, said:
Is there going to be a base-style map in the mod, or is it gonna be one long adventure like normal Duke?
Qwnz0r Qwn3d is gonna be just an episode with several long levels, without special maps dedicated to bases. Places like factories and storages will be found in urban locations among other buildings. That is, everything is integrated. As I foresee my TC by now, the first two maps are expected to take place on Earth, later the action moves into space; Duke visits a base on the Moon and then arrives to a fictional stellar system. Still it's nothing like 3DR's Duke. =)
Gambini, on Feb 27 2011, 05:04 PM, said:
Actually I meant that I can't put them into a variable (to display on the screen, for instance). But that isn't really needed in my version of the bonus screen. Maybe I'll add a "rating" thing that is present in X-COM games and tells the player how good the mission has been completed.