damainman's Forum Posts

  • Thanks for that, I somehow missed this in all the forum searching I've done.

    This is what that line ended up looking like:

    Move Self.Zsize*11 pixels at angle angle(self.X,self.Y,Sprite16.ImagePointX(self.gridline),Sprite16.ImagePointY(self.gridline))

    Need to tighten up the math now and it's almost finished.

    Again thanks!

  • I'm using both but I constantly hit walls due to missing features in C2. I find C2 is getting faster but some of the simple feature of CC are greatly needed.

    Little things like Array Paste and the ability to stop a sprite from rotating when changing an angle. I'm learning to live without the full z plane but it's causing so much extra work...sigh.

    What it took me 2 hours to do in CC has taken me the better part of 5 nights after work now. And it's still not even close to what I had in CC because I'm trying to make up for missing functions (totally fake z plane).

    I like them both, but each have their flaws. But for now, despite constant crashes - I prefer CC over C2 for functionality alone. And because my game isn't going to work for crap on an iphone or ipad or whatever because I have to use webgl for the effects I used in my CC version.

  • I would absolutely love the ability to turn off sprite rotation when moving a sprite on an angle or setting a sprite to move towards an angle using the move to angle at X pixel condition.

    Using invisible sprites that control the movement is a burden to the program I'm building, due to the maths used there are no behaviors that will work properly. Only Set Angle and move to at X pixels.

    A simple sprite property with a on off toggle would be awesome.

    Please and thanks!!!

    fake 3d engine test.

  • Never mind - ditched this for "move at angle" instead. Now the sprites do what I want but I forgot c2 rotates the sprites with the angle...ARGH!!! Invisible place holder sprites are going to cut into the speed :( Fingers crossed.

  • Thanks shinkan, that was part of the problem. But that is getting the position between of the first and second sprites origin point which is dead centre of the screen.

    The two gridline sprites get further apart as they reach the bottom of the screen. The 3rd sprite travels towards the bottom of the screen.

    I need to know what the position is between the first two sprites according to the third sprites Y location.

    That position would then become the third sprites X position. Causing it to travel on an angle according to the two grid sprites.

  • So I've been messing with that fake 3d engine and I've hit a math snag.

    I need to find the position between 2 sprites at a third sprites y position.

    say you have a gird:

    | | | | | | | | | |

    And I Want a sprite to follow an imaginary line between two of these lines:

    | | |o| | | | | | |

    How do I calculate the pos between the 2 line sprites at the object sprites y pos?

    I've tried the "distance(spriteline1.x,spriteobj3.y,spriteline2.x,spriteobj3.y)" but I'm not even sure if thats what I need here or if that is even correct.

    Thanks for the help in advance, I've been stuck on this one for two days...

    Chris

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I've got it half working but calculating the distance between the two grid line sprites at the scaling sprites Y pos I'm doing wrong. Also the math for y=self.y+zsize isn't working every other sprite is jumping around like crazy... a long ways to go yet...

    How do I get this distance properly? In my head I see:

    Get spritegrid1xpos spritetree1ypos, get spritegrid2xpos spritetree1Ypos, subtract answer 2 from answer 1, divide new answer by 2, add this to spritegrid1xpos spritetree1ypos for spritetree1xpos...

    Makes sense to me... I also needed a nap a few hours ago.

  • I don't that would quite work but it's very close.

    I don't have time to try this until after work but I think bumping the Ypos down at the speed of the zoom and getting the distance between certain grid lines at the scaling sprites Ypos might do it...

    If you just add 1 to the zoom or y pos it wont match the speed of the mode7 sprite. The y would be steady and the zoom slows down. The mode7 sprite scales on an angle and appears to go faster as it gets to the bottom of the screen despite the scale speed being steady.

    I have poor math set up to mimic the speed of the mode7 sprite but it's not 100% correct.

    Thanks for that math idea though, I think with my tweak it might work!

  • Well - I've done the end bit and the start bit but not the middle bit LOL!

    I've created a demo with the objects set to invisible. I've now created a grid with a start point on the horizon with 11 image points - one for each row. And then at the bottom of the screen there is a similar object but much bigger also with 11 image points.

    I've created lines to show the angles from sprite1's image point to sprite 2's image point. I've manage to get everything lined up with the mode7 plugin sprites. You can rotate and move up down left and right.

    The object speed is 98% correct. But here is the problem:

    How the heck to I move a sprite by it's main image point along a line like that without using the bullet behavior? Bullet causes a crazy effect and half the time it doesn't detect what it's supposed to be doing...

    So yeah, there are two image points. I want to move a sprite from one image point to another without using Bullet Behavior. The other option is following the grid sprites but I don't think that's possible. I did it just to show that everything aligns according to the POV.

    Here is a link to the 3d grid demo, arrow keys move pov:

    http://designchris.com/3dtest2/

  • Jerbens

    That's the math I was messing with and gave up. I needed a way to figure out how to move the sprite from the horizon to the front and have it angled to the camera's pov. With your formula I can already see how to shift left and right which I can't do with mine...

    I'll give your formula a try tomorrow. I've worked all day and then sat down and tackled (and won) the z-order issue I was having without compromising the speed of the program. Far too much computer screen for my eyes...

    retrodude

    Thanks! Studied animation when I was younger, Haven't stopped drawing for fun since I could hold crayons. Used to try to make c64 games when was very young too. Took programming about 15 years ago... yup. I thought it would be cool to put a game together for my daughter when she's a little older - I've actually built an arcade cabinet from scratch for it too. Needs to be finished but she's only 2, I've got at least another year to spare ;)

  • retrodude

    The way CC and C2 handle this stuff is different.

    CC actually has a Z plane so there is no extra crap required to do what I did for fake 3d. Like I said in an earlier post, it's nothing but converting the Y axis into Z and that's it. The Z plane is handled by CC. I posted the code in an older post above for CC. There is more to it than that like everything that needs to be on the Z plane is in a family and I believe the Z variable is part of the family as well. Then you add a number to Z like z=z+5 and that zooms the bits. Y converted to Z becomes the distance from the "Camera".

    None of this is technically "mode 7" except i use the mode7 plug in for the ground and sky in the C2 - it doesn't look nearly as good as the CC version though.

    My engine isn't finished. The CC one in theory can rotate 360 degrees but I have no need of doing that.

    The C2 one is only a few days old and completely unfinished. The way I'm handling the sprites angles of movement is an illusion. Everything is on a sprite that is 2000px wide and 224 high. The image point is set dead centre so when you zoom in on it, depending on where the actual image is placed within that 2000px sprite will depend on what angle it appears to be coming from.

    I'll post the C2 engine when I have it working to a level I'm happy with, as it is, it isn't handling the z plane for sprite properly and any attempt to correct it so far has cut the framerate down to 1/10th of the speed.

    I miss the CC sprite feature of for the z plane of placing an object in front of another etc. Most of the Z actions for sprites are gone. So this is a lot harder than it needs to be.

    Here's a vid of the CC version of my engine.

    Go!Go!Maddi! Welcome to the Fantasy Zone!!

  • Almost got it :) Fakey 3d!!

    So there is as close as I could get the engine started with what little amount of spare time I had today. Image points play an important part of this. They are the growth point of the sprites. The must be off centred according to where they must be on the screen when they are full size.

    Still a little tweaking to do, but there is zero slow down on my laptop. Arrow keys move the screen.

    Try not to throw up watching this!!!

  • Here is the start of a fake 3d engine build using the mode7 plugin. If the mode 7 plugin also supported an undistorted sprite that still followed the rest of the plugins rules I think the only thing you'd have to do is convert the y to z.

    As far as my construct classic game goes, there is no mode7. It's entirely sprite skewing and distortion and then converting the y axis to the z axis. The math to convert y to z is simple and once you've done that you just give the sprite a new y pos on screen. There is no bullet sprite. I believe I have the program set to "always scrolly to scrolly+12" and instead of the sprites coming onto the bottom of the screen they fade in small from the back.

    Here is an example of the code in CC:

    <img src="http://designchris.com/maddi/3d.png" border="0">

    Here is the trial and error crapola I did yesterday and the night before. I call it going nowhere fast ;)

    Construct 2 mode7 + scaling sprites not working so well yet.

    If someone can figure out the scaling sprite bit that would be great... I don't really have the time or knowledge to figure out the math :)

  • I've got it half working - everything mode 7 works 100% fine. Controls to rotate and change height are there. The Z-axis is working by converting from the a sprites pos on the maps y-axis.

    The issue is proper scaling of images to match the timing of the mode7 ground and those scaling sprites have no set point of view. they zoom front on no matter where they are. The only way around that so far is setting different sprites to have the image points off set according to how they are positioned on the screen. I've got something messy but not to where I want it yet.

    Has anyone done a proper POV sprite scaling project in C2 yet?

    Could always do 1000 layers with different scaling levels and scroll speeds as the sprite comes up on the y axis it starts hopping through the layers... lol yeah right...

  • I did the space harrier clone for the flying level of my CC game. I used the Z levels to control the scaling aspect. How can it be handled in C2? Sprite scaling?

    I've already done the sky and water using the new mode 7 effect and that rocked.

    The way my "fake 3d engine" worked was by converting the y plane into the z plane and then giving the sprite a new y location. The mode 7 effect was made by skewing the sprite to the player sprite height.

    Worked like a charm and took all of 2 hours to create. So now I'm a bit stumped because of my CC mindset.

    Unless I'm missing something the only thing I can think of off the top of my head is making something that converts the y to sprite size. I'll give that a try :)