Arcticus's Forum Posts

  • That sounds like an interesting way of doing it.

    I still would like my way though, that could give some games the option of user created levels without filling the directory with easily edited inis etc and you would also have all the other standard ini file interactions without the external files

    Or is there some sort of encryption?

    anyway it was just a thought i had that i like

  • Is it/would it be possible to have an ini file that you can read and write stuff to as usual but that is stored inside the exe?

    I don't know how necessary it would be or if it's already possible but i think it would be a cool idea for like level editors and stuff where you could store all your levels in INTERNAL ini's so people don't go around editing things like save files and levels etc?

  • Has NOBODY seen the tileset import options in the import screen!?

    I use it quite often for mucking around with RPG maker tiles

  • Thanks for before I don't expect you to go nuts on it lol

    It IS bloody hard, I just figured now we have a bunch more people on construct, there might be someone with some more insight into this sort of thing.

    Terribly frustrating i know!

    Anyways, everyone, download my link up top and mess around with the Z sorting formula and see if you can fix it!

  • Sorry to shamelessly bump this up again, but I REALLY need some help with this problem

  • i currently have one with 64 directions but i do believe that is a little excessive

    but even with something like 16 which is what i'll probably end up using, it still would be a lot easier with the suggested method.

    for anything isometric, simply rotating the sprite isn't really going to work well and if construct does get to the point where it can do iso games well, i can see this being a very useful feature

    Edit: for the record, i'm rendering my sprites. not a huge fan of rips

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Me again, just a warning, if you haven't seen it already, this is quite a wall. But please hear me out

    I've suggested this before and I've had some devs say they like it but i haven't heard of any more progress on it. I didn't know whether or not to make a new thread or necro the old one so here's a new one as I don't know if I explained myself correctly last time

    My suggestion is for those of us that like to render all our animation directions into one file/image series.

    Eg: walking right, walking down, walking left then walking left - ALL in the one animation file/image series.

    What I would like to see is on the import frames dialogue and option to create a new animation angle of X degrees every Y frames imported.

    This would DRASTICALLY steamline the animation import process because as it stands, using the current method of importing animations, the user would have to:

    1 - import the entire animation into ONE animation angle

    2 - manually enter every new animation angle (no sweat you say? try having a 64 direction animation)

    3 - Cut the required frames out of the main import animation angle and paste them into the correct animation angle

    4 - repeat till finished for each animation

    As you can imagine, for a sprite with 32+ animation angles and multiple animations, this could/does take a looooong time

    With the proposed method the user would have to:

    1 - Set the angle amount (hopefully with direction presets, eg: 2, 4, 8, 32, 64 directions)

    2 - Set the amount of frames that equal one animation cycle

    3 - click import

    Quazi kindly told us that it is a common method in game making and that games such as Starcraft even imported their animations in a similar way.

    This would make creating rendered sprites with many animation angles a breeze rather than a loathsome chore! And considering the tileset import does a -similar- type thing, I don't think it would be a huge hassle to implement.

    The only problem I can see it having would be that it would require a simple maths check to make sure the numbers add up.

    Eg: It should not allow a user to import an animation where the number of directions * frames per angle exceed the total frames to be imported.

    Solutions to this could either be:

    • import the amount of frames per angle until all angles have be filled, then discard any remaining frames left to be imported (this could also work if there are not -enough- frames for an entire rotation, just discard remaining animation angles)
    • simply prompt the user that there are too many frames for that many angles, given the data entered and correct data needs to be entered before importing can succeed

    Sorry bout the wall of text

    Dev feedback? Is this already on the drawing board?

  • Yeah i used the same method, if you hold C in my current engine it goes into a sort of 'debug' mode where you can see all the invisibles

    I was hoping that new 3d layering thing might have worked in this but alas, perspective

  • Me again, I've made similar threads like this (and hijacked others )before and since I have made a fair bit of changes to my old model, i decided not to necro one of the old threads..

    Basically, I need help fixing the sprite Z order sorting in my ISO engine. I've tried so much stuff i can't even remember it all.

    here's a link to the current version

    http://www.mediafire.com/?xyjvkxvtmo2

    As you can see, it's still not perfect. There seems to be some physics problem with disabling collisions while still trying to move but that's minor, the main problem is the Z sorting, once that's done i can start crankin out some content.

    ALL i need to get it to work, is some formula (preferably in the format of the 'for each ordered' loop) that will make the affect objects behave thusly:

    • If their Y coordinate (regardless of their height) is greater than another affected object, it will always be in front of it (i have this one solved of course)
    • If the bottom height variable (distance from the ground) of one object is greater than the top height of another affected object, it will always be in front of it (currently cannot achieve this)

    The current ineffective formula is this:

    for each Layers (family) ordered by:

    (Layers.Y + Layers.Value('ZHeightBottom')) + Layers.Value('ZHeightBottom')

    = send to front

    Ordering by the Layers.Y + Layers.Value('ZHeightBottom') solves my first problem and adds simple iso depth to the game. But it treats everything as though they are infinitely long 'poles' sticking out of the ground, sure you can go around it but you sure as hell can't sit on top of it.

    The REAL hard part is getting the player (and anything else in the layers group) to sit on top of stuff without any errors.

    Please help I know it's tricky to explain, just play the game and you'll catch my drift.

    thanks

  • Cough ......custom collision masks.

    I believe the idea he's getting at is that you can animate distort maps and therefor having a distort map with collisions would then mean an animated custom collision, practically, I'm fairly certain you cannot animate collision masks (unless i've been gone too long and you can now)

  • That's pretty sweet bro, reminds me of fallout perspective + echochrome

    I'm not sure if mine would work with your method as i'm having/going to have lots of variable heights (eg: moving elevators, jumping etc)

    I've uploaded various caps over this engine's production, if anyone wants me to upload the newest one i can, however the problem is pretty much the same in all of them.

    I was gonna say i don't like people stealing my code but i don't mind if you credit me if you use it

    But i guess i just did lol

    I've redone the graphics to be a little more consistant with the height variables and such that i was using. I made the graphics relatively hi res because you can zoom in with the mouse wheel and slow time with E and Q, i put those in for finding bugs

    wasd for moving, player always turns towards mouse. I kinda like the idea of fps type controls in an iso game, allows for precision combat (when i put it in)

    http://www.mediafire.com/?xyjvkxvtmo2

  • I'm making my own isometric engine and i can tell you now, the hardest thing to do is the Z sorting

    Movement and height i've got done, collisions are almost done (bit of a physics problem)

    But sorting has be completely stumped.

    I've tried (Y + Z) / 2 which would -seem- logical but i suppose i'm also trying to make 2x2x2 size objects work with the same logic as 1x1x1 and it's not quite working as intended

    There's no need for any other grid, you don't even actually have to have the typical diamond shape squares, the movement is the same regardless unless you're going for a more of a retro look

    I'm using true isometric though rather than oldschool iso so the old '2 across, 1 up' doesn't exactly apply

    basically, i've got a proper iso engine IF you don't want to have the Z axis. Sorting with the Z axis is a pain and if anyone can help me please do

  • um not really

    I need it to be a little more dynamic then that, the sprite is essentially controlled by the player and parts of it need to be visible when they're overlapping the mask object.

  • not quite, the whole idea is to have a portion of an invisible sprite visible when it is overlapping the mask object.

    changing the opacity would affect the entire sprite rather than just showing a portion of it

    it's ok if it's not possible, it was just an idea i was entertaining

  • Sorry to be a pain, that gave a similar result to what i wanted

    What i need is a sprite that acts as a mask for another sprite so that when they overlap the sprite becomes visible, rather than having the mask make it invisible

    hard to explain. it may not be possible considering my constraints, just an idea i wanted to try out anyway