Weapon Alpha

[Valo]

Bit of bad news. The engine is a bit well...shot. I've been trying to correct errors in the movement, errors usually only surfacing in extended play, not when i try to demo something in a gif, as i go. Movement has been having incredibly weird collision bugs and random bouts of wonky physics. The movement is old and a mishmash of various coding styles cobbled together into a "working" state, which makes debugging it very difficult. I've decided to just go and scrap all the movement code and start over. I need to redo it as cleanly as possible, and design it around the various planned floor hazards, not just archaically cram those in as i get to them into an already messy code pile. So, updates will probably slow down greatly while I redo this, and this doesn't mean I've stopped working on it. I just won't have any player-side updates for a time...

[Bombshell93]

I advise researching separating axis theorem if you'd like to understand fast and accurate collision detection, along with it, a lot of sites will have information on physics simulation and such to properly control an objects momentum. its also a good idea to learn the uses of the dot product, its the key to silky smooth collision detection, it'll start out a bit mind warpy, but it is very much like riding a bike, once you learn it you could be asked by a stranger on the street to whip up a 2D physics engine and you'll be done before they can say "why is there a computer in the high street!?"
learning this was actually my bridge out of game maker, simply because it drove my curiosity.
and ofc, any troubles feel free to ask, I'll help all I can

---

actually you know what? I'll give a go of explaining it,
Seperating Axis Theorem (SAT) is the idea that any convex shape can be checked against any other convex shape for collisions, by getting an axis of each side of each shape and projecting the shapes onto the axis (imagine if this axis was just a straight line and you pushed the shape against the line until it were flat), you can then determine whether the shapes are intersecting based on their positions on that line, if the shapes are not intersecting on 1 or more of the axes (axes being plural axis) then the shapes are not touching.
I believe this page visualizes it best, its demos are interactive,
http://www.metanetsoftware.com/technique/tutorialA.html

the concept is fiendishly simple once you understand the maths.

[TheShyGuy]

If you're daring enough, you might even look into Sweep and Prune to speed it up http://jitter-physics.com/wordpress/?tag...-and-prune .. but you probably won't need it for this game.

__

For SAT, you use the dot product project both collision masks onto each possible separating axis. Projecting onto an axis creates 1D min/max values which define the extents of a mask. To detect an overlap, you check the min/max of both objects' projections.

In the end, you get a collision system that allows collision against any kind of convex or composite-convexed shape---which includes slopes.

[Valo]

 working on implementing something a bit experimental (at least as far as my skill set goes, haha), I don't feel it is working enough or far enough along to be worth sharing outright, but I felt i should share something after so long of an absence, so I'll share this!

[Valo]

Well, getting somewhere so it's time i share what it is. A faux 3d world map! I was bored one day and started messing with a PD 3d platformer engine using the WA assets. The group seemed to like the idea but felt it wouldn't be worth while to try and stick with it. But the general comment was that it reminded them of snes era RPG maps. I figured, why not modify that engine into just that then? I was going to have a system of revisiting completed levels anyway.I've also been   trying to think of a way to implement optional levels which was hard to think of a way to get working in a menu based system. With this 3d map you can actually fly around as you please and stumble upon these levels or find clues in the main story levels about hidden areas. These will be represented as coordinate style clues, tho not really realistic as only x and y coordinates will be used. You can then travel to those coordinates within the map using the hud on the left. In the final, both your x and y coordinates will be updated in real time for use in navigation, as well as that green screen displaying multiple compass points. There will be a consistent point that will always point north like a real compass , a story objective point which will point you to the next story level, a sidequest point which will point to a set sidequest that you've unlocked(one of which will involve that big robot from the sprite thread !). The sidequest marker can be swapped out as needed if you want to drop a sidequest and tackle a different one, or turned off completely. And lastly, a player defined point. Some where you can mark on the map yourself if you want to remind yourself to come back there later.


I've mostly gotten the hud working. Having a bit of an issue getting the engine to actually use my all purpose sprite based font, which likely means theres another object defining the font besides the hud object, will work that out soon. As well as figure a way to get the font to render over the hud, since using the draw event makes sprite depth wacky... I have the next few days off so i wanna tackle this as much as I can.


You may notice the land masses pop in oddly at times in the gif, this is due to having the ship set up to 'wrap' to the other side of the room when it reaches the room border. Basically meaning the game teleports your ship to the other side of the map, even if it will spawn you 3 feet from a face full of wall. In the final, we'll have enough buffer water space there to run out most of the draw distance, so when you hit an edge you wont notice any pop in.

Textures are place holder as well. They feel a bit too complex for WA's graphic style in my opinion. The water too, though i'm quite happy with how that turned out unrelated to WA, haha. 

The creator of the original engine will be credited of course! ...I i just need to find their name again. It wasn't listed in the engine proper.

[Bombshell93]

this is freaking gorgeous!

[Valo]

Green is compass, always points towards the north. Red will be the story objective pointer( tho i dont think woodman has any interesting stories to tell!). I think in final I'll use a brighter red or add more white to it so its more easily seen. I think that the sidequest pointer will go on the same inner ring as the story one, and the player defined 'reminder' marker will go on the outer ring with the compass. Thoughts so far?

[StarSock64]

I'm diggin' it

I think you're right that the red needs to stand out more, but I think that making the green radar (not the north mark) less intense would be better than trying to make the red more intense (or else try both)

[Valo]

I'm diggin' it

I think you're right that the red needs to stand out more, but I think that making the green radar (not the north mark) less intense would be better than trying to make the red more intense (or else try both)

so make it a darker/duller green you mean?

[StarSock64]

yep, that sounds like a good idea to me

[Valo]

I've a bit of a conundrum. Perhaps you guys can help shed some light on it? 

See, I'm trying to change the way the map renders the sky background. Currently, it renders it by pasting a texture onto a cylinder thats wrapped around the room. This causes a few issues, namely that it warps the background and the 'polygons' of the cylinder become very noticeable depending on the room size.  The latter i know can be fixed by changing the number of steps variable in its argument, but it doesnt really fix the big warping issue. So I had a thunk. What if i use a similar method to how the hud is spawned and render the background as a sprite? Its doesnt have any details that would move or would need to rotate as you look around, so I'm wondering if making it a drawn sprite would work. Issue is is that I can't quite seem to get it to work...Everytime i try to render it using the same style as the hud, the room ceases to render in 3d. and i'm left with a sprite covering a big chunk of the view. 
For reference:
Cylinder type Mock up of what i'm trying to do(all textures are placeholders and/or tests of course)

The cylinder spawns via:

d3d_draw_cylinder(x-1024,y-1024,global.bg_z2,x+1024,y+1024,global.bg_z1-300,sprite_get_texture(global.bg_spr_tex,floor(bg_frame)),global.bg_hr,1,-1,16);

and how I THINK the bg would be rendered is:

d3d_set_projection_ortho(0,0,global.range_x,global.range_y,0)

draw_spritxt(spr_bg_tex1,image_index,0,0,image_xscale,image_yscale,image_angle,image_blend,image_alpha)

I'm not sure if thats enough context to help relay the problem, I can give more if needed. Does anyone maybe have an idea of whats gone wrong?

[Valo]

I tried setting the opacity of the background to half to see what was going on after it is drawn. It seems everything is in tact, but it is drawn over everything. I remember when trying to implement the distance fog, i had to be careful of the order of draw code  events so everything would layer properly. I wonder if the issue is something that simple?

[Mag]

Looks like you're using Game Maker Studio by those function names.

If you want, you could use a shader to apply effects like distance fog and a static sky. I've made a photoshop shader pack that could serve as a bootstrap for making shaders in any game.

Here's a quick fog shader I cooked up just now (This would need to be applied on all objects that you want fog on, for :

Code:

//
// Fog Fragment
//
attribute vec3 in_Position;
attribute vec4 in_Colour;
attribute vec2 in_TextureCoord;
attribute vec3 in_Normal;

varying vec2 v_vTexcoord;
varying vec4 v_vColour;
varying float depth;

float view_far = 10000.0;
float view_near = 1.0;

void main()
{
    v_vColour = in_Colour;
    v_vTexcoord = in_TextureCoord
    
    vec4 object_space_pos = (rot * vec4(in_Position, 1.0)) + vec4(gamePosition, 0.0);
    vec4 viewPos = gm_Matrices[MATRIX_WORLD_VIEW] * object_space_pos;
    
    depth = (viewPos.z - view_near) / (view_far - view_near);
    gl_Position = gm_Matrices[MATRIX_WORLD_VIEW_PROJECTION] * object_space_pos;
}

[TheShyGuy]

Yeah, it looks like it's an issue of the background's depth. The draw order doesn't necessarily matter since it's 3D, you're only drawing opaque objects, and you're not trying to optimize anything. Though, I don't know how GM handles 3D so I could be wrong about the draw order. You should check the docs to make sure it's doing what you think it is.

[Valo]

Yeah, it looks like it's an issue of the background's depth. The draw order doesn't necessarily matter since it's 3D, you're only drawing opaque objects, and you're not trying to optimize anything. Though, I don't know how GM handles 3D so I could be wrong about the draw order. You should check the docs to make sure it's doing what you think it is.

I think it might be the draw order. I had to check when i implemented the fog. The fog kept going over the whole screen, covering the background layer until i changed the order i drew the fog and backgrounds in. Whats weird this time is I had to spawn a separate object to draw the background graphic or else the ortho bit would negate all depth and 3d code. Weirder still is that it only works when i set the depth between 0 and 3.  Certainly an odd case this one...

---

Looks like you're using Game Maker Studio by those function names.

If you want, you could use a shader to apply effects like distance fog and a static sky. I've made a photoshop shader pack that could serve as a bootstrap for making shaders in any game.

Here's a quick fog shader I cooked up just now (This would need to be applied on all objects that you want fog on, for :

Code:

//
// Fog Fragment
//
attribute vec3 in_Position;
attribute vec4 in_Colour;
attribute vec2 in_TextureCoord;
attribute vec3 in_Normal;

varying vec2 v_vTexcoord;
varying vec4 v_vColour;
varying float depth;

float view_far = 10000.0;
float view_near = 1.0;

void main()
{
    v_vColour = in_Colour;
    v_vTexcoord = in_TextureCoord
    
    vec4 object_space_pos = (rot * vec4(in_Position, 1.0)) + vec4(gamePosition, 0.0);
    vec4 viewPos = gm_Matrices[MATRIX_WORLD_VIEW] * object_space_pos;
    
    depth = (viewPos.z - view_near) / (view_far - view_near);
    gl_Position = gm_Matrices[MATRIX_WORLD_VIEW_PROJECTION] * object_space_pos;
}

Gm 8, actually. I was using 8.1 and hated the room editor before they fixed it so i switched to 8.0. And now that studio is out i'm too far along to smoothly port over the engine, and the fact that the few people in my little dev group off site only work in 8.0 as well, and thus we couldn't share edits easily.

Tho I'll look into your suggestion, hopefully its 8.0 compatible.