The VG Resource

Are you sure that draw_spritxt is for 3D rendering? If it's only for 2D drawing, then setting the projection to ortho shouldn't do anything. You could test that idea by setting the projection to perspective and seeing if the background is rendered appropriately.

Take a look at d3d_draw_wall. You could use that to draw the background with an appropriate Z depth along with an ortho projection. Note that in order to have the background static, either draw the background in a fixed position and use a static camera view matrix, or you can set the background's world position relative to the camera every game step along with making the background always face the camera (i.e. billboards). The first is the simplest approach.

(08-15-2015, 11:15 PM)Valo Wrote: [ -> ]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.

Sorry, shaders were only added in Game Maker Studio, so I guess that won't be a possibility.

I can understand the pain of upgrading. Studio broke code execution while the engine is running (so no execute_string), but most stuff stayed the same, and there's tons of new features (OpenGL Wrappers, Networking, Cross platform support, C++ Compiler) so it could be something you might want to consider once you guys get closer to a stable release of the game.

There's d3d_set_fog(enable, colour, start, end) if anything.

(08-16-2015, 12:57 PM)Mag Wrote: [ -> ]

(08-15-2015, 11:15 PM)Valo Wrote: [ -> ]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.

Sorry, shaders were only added in Game Maker Studio, so I guess that won't be a possibility.

I can understand the pain of upgrading. Studio broke code execution while the engine is running (so no execute_string), but most stuff stayed the same, and there's tons of new features (OpenGL Wrappers, Networking, Cross platform support, C++ Compiler) so it could be something you might want to consider once you guys get closer to a stable release of the game.

There's d3d_set_fog(enable, colour, start, end) if anything.

oh, I already got the fog working, it just doesnt render right as long as that background issue exists! 

 excuse me while i go cry in the corner because it took me over a week of trying various methods to learn i just need to add one line of code before the drawing background event. d3d_set_depth...

 textures are getting a bit more solidified, i tried adding in a land mark to use as a level select thing, this floating island is known as uncanny valley, and its level would be the purple mechanical floors and rain tiles ive shown a bunch before. problem is...I set it too high which reminded me, i never modified the 3d engine to have altitude control, I'll be working on that. Should be simple enough, the base engine had jumping, should be able to modify/offshoot that into what i need. 

First thing i wanted to take care of was making sure the camera follows the ship's Z position. Was....actually a lot easier to do than i was anticipating which is nice. 
 First isue tho is that it looks like jumping causes the cam to zoom in slightly, but i think thats handled through the player object, since the old dash function causes the camera to zoom out too... Something to dig through tomorrow I'm sure. Anyway.
I'm sorry i haven't had a lot of meaningful updates recently. Real life stuff and such(nothing bad, don't worry! just busy) I'll try to get more regular and meaningful updates lines up.

For now I leave with survey type question. Do you think it would be a good idea to add a z-coordinate display, or do you think that would be a meaningless part of the hub since i doubt any landmarks would stack over each other?

@Valo, this project has extreme promise and I look forward to being able to one day play it! As for GM, I happen to be pretty familiar with it so If you need assistance feel free to message me.
I love the over world idea, maybe make the green dot an "N" though with the image_angle() command may make it illegible, worth a shot though.
As for your question I wouldn't fret over a Z varible tracker, seems pointless as you said yourself; I doubt any landmarks would stack.

The rest of the game looks very good, I love your boss concepts as well as the general animation is superb! I wish you the best of luck.

Thank you Mat, I really appreciate that. It's always good to have more people to get feedback or advice from!

Now let me shift gears for a moment, because I vaguely remember this game being primarily 2d haha


I actually got something working on the first try for once \o/

Whats going on is that the player is now made of two sprites. Separated by his upper body and the waist down. That blue dot causes the upper sprite to change into a blue recolor. But it is not a color code, it is actually loading in a new sprite. I've implemented this to allow Valo's look to change as he acquires new equipment. I'm unsure if I'll make it so you can swap out equipment or just have things stack with a permanent graphical change. The code is actually pretty simple....which might explain why it worked on the firST TRY BUT I WONT LET YOU TAKE THAT SMALL VICTORY FROM ME!

Quote:When i code valo's movement, i still code his animations as if they were generic and simple sprite changes, but in his draw, will be something like the following. the generic animations i code valo with are made invisible by editing in the sprite editor, not code. I do this so valo has an 'animation skeleton' of sorts where i paste two skin sprites over it, an upper body sprite, and a wist and lower sprite. the following code is just for an upper body

//Draw the sprite as gamemaker would do so originally
draw_spritxt(sprite_index,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha)

if armor=1{

if sprite_index=spr_idle{
draw_spritxt(spr_torsoarmor_idle,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

if sprite_index=spr_valo_walk{
draw_spritxt(spr_torsoarmor_walk,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

if sprite_index=spr_valo_shoot{
draw_spritxt(spr_torsoarmor_shoot,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

if sprite_index=spr_valo_backflip{
draw_spritxt(spr_torsoarmor_backflip,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

if sprite_index=spr_valo_jump{
draw_spritxt(spr_torsoarmor_jump,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

if sprite_index=spr_valo_run_shoot{
draw_spritxt(spr_torsoarmor_runshoot,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

if sprite_index=spr_valo_run{
draw_spritxt(spr_torsoarmor_run,image_index,round(x),round,image_xscale,image_yscale,image_angle,image_blend,image_alpha) }

}

-quoted from a hasty pastebin i was using to explain it to someone, please forgive typos and such.


I've got the 2d engine almost back up and running now, if anyone recalls that I wanted to restart it. Theres still a minor collision error that keeps happening though, and it is hard to correct because i cannot reliably recreate it so i cannot clearly ascertain whats causing it. Occasionally when you jump at a wall that is juuuuuuust at the maximum height of your jump, and you bump the edge, the player rockets back down using the same code that happens when they conk their head on a ceiling, and it only happens SOMETIMES and I cant figure out why...

You could try something like this to advance your event check ig: player's vspeed=0 so he is idle
(Then you might be able to condense your armor switch code as well as the normal sprites, based on movement variables)

If you give me your variables I could edit this code more for you.
though this may be plug and play; fair warning please back up before trying this. Though the code has no syntax errors.


Hope this may help, even if you don't use it you could learn from it. You seem to be a promising coder ^-^

(08-31-2015, 07:57 PM)Mat(Nerah) Wrote: [ -> ]You could try something like this to advance your event check ig: player's vspeed=0 so he is idle
(Then you might be able to condense your armor switch code as well as the normal sprites, based on movement variables)

If you give me your variables I could edit this code more for you.
though this may be plug and play; fair warning please back up before trying this. Though the code has no syntax errors.

Code:

//Idle
if armor=1 && vspeed=0
   then sprite_index=spr_valo_idle{sprite_index=spr_toroarmor_idle}
if armor=1 && hspeed=0
   then sprite_index=spr_valo_idle{sprite_index=spr_toroarmor_idle}
   
//Jumping (Rising/Falling)
if armor=1 && vspeed<1 or vspeed>-1
   then sprite_index=spr_valo_jump{sprite_index=spr_toroarmor_jump}
   
//Backflip
if armor=1 && backflip=true
   then sprite_index=spr_valo_backflip{sprite_index=spr_toroarmor_backflip}
if armor=1 && backflip=false
   then sprite_index=spr_valo_idle{sprite_index=spr_toroarmor_idle}
   
//Shooting
if armor=1 && shooting=true
   then sprite_index=spr_valo_shoot{sprite_index=spr_toroarmor_shoot}
if armor=1 && shooting=true && hspeed<0 or hspeed>0
   then sprite_index=spr_valo_run_shoot{sprite_index=spr_toroarmor_run_shoot}

//Running
if armor=1 && hspeed<3 or hspeed>-3
   then sprite_index=spr_valo_run{sprite_index=spr_toroarmor_run}
//Walking
if armor=1 && hspeed<=1 or hspeed>=1
   then sprite_index=spr_valo_walk{sprite_index=spr_toroarmor_walk}

//Draw our player
draw_sprite_ext(sprite_index,image_index,x,y,flipped,image_yscale,image_angle,image_blend,image_alpha)

Hope this may help, even if you don't use it you could learn from it. You seem to be a promising coder ^-^

I'll certainly give it a shot in the morning, though I'm hesitant to use it if it does work. I'd prefer not to use speed checks to define states, as this can lead to screwynes when moving platforms get involved. Or i may be overthinking it and it might not cause any issue.

(08-31-2015, 10:00 PM)Valo Wrote: [ -> ]I'll certainly give it a shot in the morning, though I'm hesitant to use it if it does work. I'd prefer not to use speed checks to define states, as this can lead to screwynes when moving platforms get involved. Or i may be overthinking it and it might not cause any issue.

Moving platforms should be fine, considering I haven't had issues on my end.
Since the way the platforms will work with the player, doesn't actually change the players variables, rather it just glues the player to it.

When the time comes for ladders use
if vspeed<0 or vspeed>0 && place_meeting(x,y,ladder)
then sprite_index=spr_valo_climb{sprite_index=spr_toroarmor_climb}

or something like that. Anyhow let me know how it goes, Ill be around later tomorrow.

Determining the absolute character state every frame is tough to manage, debug, and easily allows for bugs. Why even determine the state of the character every frame? If you begin to climb a ladder, why determine that you're doing that again every frame? Instead, I prefer tracking the current state, for example "idle", "jumpRise", "jumpFall", "walking", "running", "climbingLadder", etc. This also allows state changes and code to be relative or local to the current state instead of the character's absolute state. I believe people call this a state machine, which you can look up for more info.

You are pretty brave to get into GM's 3D side. As you have probably noticed it you definitely notice the additional D when it comes to coding complexity.

I have never had the patience to deal with 3D so I still use 2D myself. I still use 8.0 too but I probably would have 8.1 if it didn't reject my code when it offered the free upgrade.

Finally. Turns out that gm doesnt like it when you do a lot of sprite edits en mass, and will crash on you out of spite. TWICE. But finally the players sprite is properly split, most of the place holder anims are gone(still not sure of the double jump effect so it remains) and a minor design revert was done. 
The new design actually predates the white collared one, though a backpack with no means of staying on a person doesn't make much sense, huh?
I hadnt had a chance to test the code you suggested since i was spending what little time i had the last few days redoing work that gm crashed/corrupted, So I'll give that a go in a bit.

okay, armor frames are updated and split.The process is oddly tedious and time consuming... Now I need a bit of help if anyone is familiar with image angle code. The idea is the armor has a scarf that I'm making the tails a separate object, though i guess it can be a drawn sprite instead come to think of it... Anyway, I want this scarf to dynamically 'spin' around the staple point depending on the players movement speed, so that it has a slight illusion of clothyness to it. I'm not quite sure how to work out the math for that though, and if anyone can point me in the right direction i'd greatly appreciate it. Oh! in that image, the players 'animation skeleton' is still rendered for debugging purposes, thats what that yellow peaking behind the sprite is.

well, if this is to be programmed, think on the scarf as an arrow. It will point down as you're stopped and when you're moving it'll point to the opposite direction.

now, i don't know how rotations are programmed nor how to do the first part i said myself - but basically I'd imagine being that way.