Mr. Project DX

Discuss and unveil current Marathon projects.

Re: Mr. Project DX

Post Feb 24th '19, 14:19

thedoctor45 wrote:considering the fact that Halo featured mostly huge organic looking outdoor areas I'd say Halathon's defnitely more on he crazy side here. ;D

Which put to the question if the project is going to have natural environments like parks or forests. It might have been announced but I need to question it anyway.

Anyway, so how's Halathon's development?
Screamernail

Post Feb 24th '19, 19:56

wow, I continue to be impressed with this project
User avatar

Pfhorrest
California

Post Feb 24th '19, 23:25

Screamernail wrote:Which put to the question if the project is going to have natural environments like parks or forests. It might have been announced but I need to question it anyway.


Well, so far there is grass. I imagine I could do trees.

Pfhorrest wrote:wow, I continue to be impressed with this project


Thank you! I think it will be done sometime this year, maybe? Haha.

At the moment I'm doing a thing to involving switches on transparent sides. Because of the scarcity of scenery object slots, and also because I don't want to have to map anything smaller than 1/8th WU for a switch.

Image
User avatar

Ku-rin
Not Invented Here

Post Feb 25th '19, 06:11

So, the engine just does not seem to want to do this. Luckily, the reason I want to do this gives me an out. ^_^

Normally you get a switch texture and you're basically saying that if you will have a switch, it will take up an entire side. There is nothing that says your switch texture can't have switches shorter than 1/8th of a WU on a side. Lots of my textures are smaller than that. It didn't make sense with 128 pixel bitmaps, but with high-res textures you're okay there. If you work with 1024 pixel bitmaps, you're looking at 64 pixels at 1/16th of a WU, which is passable.

But maybe you don't want to keep switching scale in Weland each time you want to just pop a switch somewhere, maybe you don't want like 50 different height settings that involve dividing to 16ths? Maybe you want tiny dainty switches without the pain of tiny dainty mapping? What ultimately then ensues begins with the basic double-texture trick, where you overlay a transparent texture over another texture using a split poly. In the time honored methods of yore, one might often delete that extra polygon once everything looked nice. In this case, we're using the polygon... for reasons.

Image

The switch texture involves some transparency. So, instead of a box shaped polygon, you can just make triangles (and those triangles can be 1/8th WU for simplicity's sake), and overlay a switch texture that may be smaller than 1/8th, and may also be any damn shape you please without needing to worry about the surrounding texture. In this example, I've used a rounded rectangle. Instead of four switch subtextures at 256 pixels each, I can do 16 that fit in a 128 pixel square. With some margin around each one to prevent bleed-thru with bump mapping, you can put an absolute butt-load of switches into one bitmap, depending on scale and so on. The switch I have here is 128x64 pixels in a 1024 pixel bitmap, so I could fit as many as 32 in one frame, assuming they're all the same size.

Image

So, you have a switch texture, but you cannot push said switch when it is on a transparent side. The switch does nothing by itself here.

That is where our triangular polygon comes in. I've done similar stuff with decal textures. Circular, triangular, and other odd shaped signs overlaid upon varying textures. At the very least, you need to flatten that polygon to make it look right. Therefore, we know that each polygon with a decal in front of it should have zero area. You can iterate through each of the polygons and find the ones you want through .area, then. We then look for a transparent side on at least one of the lines, and make sure that said side's transparent part's texture index is less than 2 (since I'm still using the switch slots as is.) If we see all this to be good, we know our polygon with the switch does a thing. [MUp]

Polygons do lots of things normally, even terribly complicated stuff like turning platforms on or off. If I set my little triangular (flat) polygon to the "platform on" type, we will know that it has a permutation equivalent to the platform's polygon index, no? Said polygon knows what platform to activate!

So, if we did ourselves a favor, we did something during Triggers.init() whereby we made a table with all of these switch polygons. We probably added some custom fields or some such that says "Me, me, I'm a switch man!" and maybe even gave it some methods to do the needful.

If you're as hyped as I am about looking at sides when a player presses the action key, you probably already have a function that looks at :find_target for that information and more to call other functions. If in fact the player interacts with a side belonging to some such switch polygon, it should then naturally engage said functions necessary to get a platform moving.

That's easy enough, as far as I can tell. I'm there, had the soup, got the t-shirt... It works! The next trick is to add a dealie to a table of dealies that are constantly queried during Triggers.idle(), so that once said platform's state changes again, you can swap the side's texture index just like a real switch. I guess I should probably just go ahead and write a generalized script for such deferred events, watchers, promises, etc. as it seems useful in many situations.

Is this as versatile as switches in general? Maybe, maybe not. When all is said and done it's not much more complicated than switches as is. Mapping triangles instead of boxes, editing the switch's behavior in Weland, that may be even less complicated than the status quo. Specifying all of the behaviors of switches? We will see. I don't think it will ever be that good, but where some random platform/door is concerned, I think this works better for me and MPDX. Light switches are basically in the same boat, tags might be trickier.
User avatar

Ku-rin
Not Invented Here

Post Feb 25th '19, 06:59

Neat! I do already make use of :find_target for secret experiments, it hadn't occurred to me to use it to duplicate how things normally work.
User avatar

ravenshining
Hawai'i

Post Feb 25th '19, 18:21

Screamernail wrote:Anyway, so how's Halathon's development?


I don't want to derail this topic so I'll make this short:

Basically most of the interior designs are complete - I'm having mostly trouble with getting the outdoor areas to look decent in the Marathon engine - the main problem here is the lack of suitable/tileable rock/cliff textures since the ones from Halo don't work - once I can find some decent looking replacements I should be able to finish the demo release swiftly.
User avatar

thedoctor45

Post Feb 26th '19, 03:33

ravenshining wrote:Neat! I do already make use of :find_target for secret experiments, it hadn't occurred to me to use it to duplicate how things normally work.


It turns out that it's better than duplication. I've been able to extend switch functionality simply because I have to control everything the engine was doing with control panels to begin with. If you're going to bodge something with Lua, best to go overboard.

This probably isn't applicable to most projects, but because MPDX doesn't have recharge terminals, I've just gone ahead and used those slots for additional switch states in the name of simplicity. The neutral and damaged states are sort of a remix of the 'light dependent' option, except the controlling light is that of the floor of the flat split poly behind the pseudo-switch, and these have different outward appearances.

Image

Having done that, I also decided to create a subtype of platform switch that varies the switch display state with the direction the platform travels in. So instead of on/off, it's up/down. I use the 'locked' parameter on the platform (which wasn't doing anything anyway) to distinguish the two.

And I can do pretty much whatever else I want by popping an annotation into the flat split poly, like add a key needed to unlock said switch. So, yeah, you can probably recreate everything normal switches do and then some.
User avatar

Ku-rin
Not Invented Here

Post Mar 1st '19, 05:34

More evil spoilers for people who hate such things...

Image

Image

Image

Switches are pretty much doing as well as ever. It's just a matter of time in Blender, time in GIMP, and inspiration now, the code is pretty much baseline here for such things. Elevator stuff meant I added some glows for disabled and destroyed panels as well. So 3 out of 16 switches, unless I want to make a switch bigger, a switch too far.

I guess tomorrow I should mess with elevators, both textures and lua. It's pretty simple, since these aren't some kind of intra-level multi-stop thing, just lua inter-level stuff with a HUD interface, which means going back to HUD and adding more state-specific stuff. I should probably just go ahead and start working on a HUD/Lua thing again. As you may see I spent today playing with a sewer, as all good games must have a sewer, or two, or infinities? Darkness ensues.

Serializing and encoding all the necessary stuff for the HUD through the palettes is about a decade old already, give or take? Hacky whacky stuff (works for Vasara, but...) and yet, I get scolded by Momma Tree-llama for trying to use native Lua I/O for passing stuff like I'm passing notes in class. I will mend my wicked ways, of course. New slogan: "Save the drama for yer momma, Pfhorums."
User avatar

Ku-rin
Not Invented Here

Post Mar 15th '19, 00:32

Ladders are pretty much good. Elevators are looking good.

Image

Image

Biggest question with ladders is transition to mounting the ladder. My solution is a linear transition of the player's position and facing across a set number of ticks, which looks okay. I'm using internal velocity to control ascent and descent, so I adapted Crater's approach from Better Bridges, shifting the player to the ground in-between drawing. To deal with media I also change the polygon's media at the same time and cancel out oxygen loss when the player's head is above the media during the post-idle.

Elevators are stupid simple, since I'm not moving anything, just transitioning the player to a different level. A delay prior to doors opening simulates the movement of the elevator, both inside and out. Still have to work out persistant variables and HUD interface for the most part, but for now I can summon an elevator and get the doors to slide open nicely. It interfaces with the transparent-side switches so that when the doors open the elevator button changes. All I need now is a nice "DING" noise.

Given the transition scripting for getting on/off a ladder, I'm going to use the same for climbing up ledges. It makes ladders more versatile because you can grab onto a ledge from a ladder and it looks smooth. When I get into jumping more seriously, I'll look at jumping from ladders. Right now you just release yourself from the ladder, and that's about it. I've limited the look range while on a ladder to 100° on either side. Aside from this, you can hit switches and basically interact with the world while on a ladder. When I get into weapons, anything that needs two hands will be disabled, and anything that uses one hand will slow you down.
User avatar

Ku-rin
Not Invented Here

Post Mar 15th '19, 01:46

With your scenario being dependent on 3D modeling, are you attempting anything to avoid the clipping issue when sprites intersect the wall or floors and 3D models are enabled?
User avatar

ravenshining
Hawai'i

Post Mar 15th '19, 04:04

ravenshining wrote:With your scenario being dependent on 3D modeling, are you attempting anything to avoid the clipping issue when sprites intersect the wall or floors and 3D models are enabled?


Not at the moment. You'd think after 10 years I'd have dealt with that, but I've been taking just so long to get 3D models that don't disappear randomly or clip through themselves! Haha. Honestly I've seen so much dodgy stuff over the course of my many awful experiments that I've probably become numb to clipping.

In all seriousness, having read your previous thread about this issue, I wouldn't think any clear solution would occur to me that you haven't already thought of. If it's just the way the engine is sorting depth with 3d objects in play, the actual answer to that problem is beyond my ken.

If a wild-ass guess suffices... 3D replacement projectiles and effects might work? Yeah, let's just make everything 3D. Though I'm not even sure how animated 3d objects are supposed to work anymore, I forget where I last saw those in the wild, if anywhere. Even if you didn't want to go and model the effects in 3d themselves, you could even just make two decals for each effect, one for floors/ceilings, one for walls, rotate the facing on walls to position them normal to the impacted surface, and simply copy over frames from the sprites if that was a thing. Again, I have no idea how animation with respect to 3d replacement works in Aleph One... I just move my models around with Lua, haha. Really, I'm only clever enough to survive being stupid in other departments, most of the time.

At a glance, it seems that you can change the facing for effects with Lua. Maybe adding more views to the effects sequences and rotating wall hits normal to the face would help the clipping be less obvious, or just look intensely weird/stupid? Won't help for detonations on floors/ceilings. Might be neat to play with, although I don't think I will at this very moment. If you try this, let me know.

Beyond that... I forget if a larger projectile radius might help by providing a stand-off for detonation upon collision with a surface. I'll probably look at that again once I get back into projectile physics at some point down the road. If that's the ticket, then it's just a bunch of trigonometry, or more likely titration until the clipping is less irritatingly obvious if not entirely gone. Pistol bullets the size of watermelons might be another problem, on the other hand.

If it ever bothers me enough, I'm sure I'll dive into looking at ways to mitigate it, but for now I hope these ideas are at least amusing if not useful.
User avatar

Ku-rin
Not Invented Here

Post Mar 15th '19, 05:03

The obvious answer is to use an engine more suited to what you're trying to do. But what's the fun in that?
User avatar

Wrkncacnter

Post Mar 15th '19, 05:17

I suspect that the effect.facing merely determines which view of the sprite is displayed, not the plane onto which it is rendered, which as far as I can tell always faces the observer. If this were not the case, we would be able to see perspective effects on sprites when looking up or down at them. Thus, having multiple views and changing the facing would not help very much, as it would just draw a different bitmap, still clipped into the wall. You might make that bitmap offset to the left or right so that it doesn't clip, and that might work for a bullet ricochet, but not for large, spatially important effects like a rocket explosion.

What I'm thinking of doing, if I delve into 3D modelling, is to create Minecraft:shrub-style 3D models onto which to map effects sprites, and flat squares for dead bodies rather like Tacticus's "3D" M1 papers.
User avatar

ravenshining
Hawai'i

Post Apr 18th '19, 23:01

Textures are pretty much stabilized for now. If anyone needs some contemporary Earth-like textures in the meanwhile, let me know. Re-did animated water.

Image
User avatar

Ku-rin
Not Invented Here

Previous

Return to Projects



Who is online

Users browsing this forum: No registered users