PixelRebirth's Forum Posts

  • As I look at it, I don't think COnstruct is able to make a movable menu screen.

    Construct surely is very able to do so! It's just a matter of how much effort you're willing to put in. Of course there's no easy way of doing this. Meaning there isn't an inventory/rpg object or something similar. So you'll have to invent your own system with events. Very possible, definitely not so much on the easy side. I bet lucid will post telling us how easy it'll be with S though.

    But I don't know... Can anyone recommend steps or pseudos on how I can do this? ANything as long as I can make a unique menu system for my RPG.

    Since this interests me as well, I will try to come up with a basic example for something like this. Will take me more than 5mins, so you'll have to wait for it. Unless somebody else is faster or has already a working example.

    EDIT: TheJanMan, check your PM!

  • Hey thanks again PixelRirth! your becoming my personal mentor

    Okay, this means you would have to pay me.

    that shortcut saves me time although i didnt seem to find any reference for that

    I recall figuring it out by accident. It might be stated somewhere in the wiki I don't really know.

  • Hold CTRL and use Mousewheel Up/Down to zoom in/out of your layout.

  • Just recently this topic came up again. So this is the thread for you: Puzzle Help

  • If you only need to remember simple things, like player stats and position, I'd simply use a hash table and save it as a random file. It's not that easy editable compared to having it in a txt or ini, where all the values are just out in the clear for everyone to see and edit as they please.

    A very basic protection would also be what Minor describes in this thread: INI Protection with CRC32

  • It might not be a good way if graphics cards commonly override the setting. You're best off using Set Display Resolution, zooming in, and setting Point sampling.

    I have been doing this so far for most of my games. However it causes numerous problems. For example the placement of objects on Scroll Rate 0% layers will get messed up (it didn't do that in very old Construct versions btw). And eventually objects placed at the edge of the screen might be shy one pixel when zoomed, showing through the background. I guess that's why some people were importing their graphics double-sized to avoid the zoom.

    So I'd really prefer using the window object like in this example, although the graphics card issue makes this method less recommendable. I'd love to just have a runtime option to make the game double-sized.

    I have no way of knowing if this is the problem

    just an idea to try

    but for those having the problem

    see in your graphics card settings if it's overwriting the application settings for anisotropic filtering

    I checked my settings, but anisotropic filtering is set to application controlled. So I guess that isn't the cause.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I doubt anyone has made a Timeline tutorial so far. If somebody knows better, put the link in here pls.

    Why don't you just try it out a little and if you get stuck, ask questions about the actual problem you're having.

    I used the Timeline object only once so far for a boss fight. It's pretty self-explanatory for the most part. Maybe you should just give it a try first, check out the available conditions/actions for the object, etc.

  • The problem is (i hope that i understand) that i have already done these.I hope at least i have done them correct.

    I have created a seperate layer to make my HUD just as the HUD tutorial.

    Also i was meant to say Scroll rate Y considering my problem.Iam sorry for that.

    You did set Scroll Y Rate to 0%, however you put the HP bar out of the screen. Like I said before:

    You have to place your HUD stuff in the layout relative to the first outlined screen. Your HP bar sits all the way down in your layout, so it won't be visible.

    To be clear: when you start out in the layout editor, there's one outlined rectangle which represents your game's window/resolution. So place all the stuff on a Scroll Rate 0% layer inside this rectangle in order for it to appear on the screen. It doesn't matter that your game is actually starting all the way down in the layout.

  • You have to place your HUD stuff in the layout relative to the first outlined screen. Your HP bar sits all the way down in your layout, so it won't be visible.

    Also for a HUD like that it's the Scroll Rate you want to set to 0%. In your case it would be enough to set Scroll Y Rate to 0% for the HUD layer.

  • That's totally cool. I bet somebody while use this principle in a shoot'em up soon! So many possibilities.

    All the S stuff is really overwhelming, great job lucid!

  • You can see where I am go with this. "Construct TBS" is on its way.

    Haven't seen anyone doing TBS yet. Looking forward to this!

    <img src="http://img204.imageshack.us/img204/5898/puzzlefudgemockup00.png">

    tile sliding puzzle game that's filled from bottom.

    <img src="http://img442.imageshack.us/img442/2046/shmupmockup00.png">

    shmup done with gameboy res.

    Awesome pixels you got there mattdubs! And that shmup looks mighty fine!

  • I guess it has to do with different graphics cards.

    Yes, it's a graphics card/driver issue. On my older computer with geforce 6600gt it does the bad bad blur thing, but on my newer one with ati 3870 it looks perfectly crisp!

  • Oh the window object... another thing I never used, although it's so useful.

    Unfortunately I get blurred little kitties here when resizing, while simple zoom 200,200 is still sharp. I take it that doesn't happen for you guys?

  • Just a little heads up here mattdubs...

    I got my own puzzle engine up and running again, complete with field generation, matching block recognition, destroying and spawning of new ones to fill up the gaps. It's made much smarter than the old version, using no detectors or any of the old stuff which I refer to as "MMF-style" sometimes. Although I'm pretty sure it could still be improved upon a lot, with smarter usage of certain objects. But I'm quite happy already in using an array, even if it's just to a pretty limited extent.

    It basically uses the same principle as the stuff I put in your cap. But there's one major flaw with that version, since it only works properly while the playfield is full of blocks. So it doesn't recognize gaps which will cause problems, matching blocks wrongly. Just wanted to let you know, because I was confused about it for a sec myself when I realized it didn't work quite right just yet. Maybe you figured it out already or made your own different engine, I don't know. But if you're having trouble with the gap recognition, let me know. It's just a minor change to those events.

  • It's being asked all the time in one form or another. Should be sticky somewhere or something I don't know.

    Add another family to your Spider sprite. Now check for overlap between those two families instead of using the sprite itself and one family. Should work like a charm now.

    So your events could look like this (while Vermin is the new family):

    [Condition]When Bugs Life=0:[Action] Destroy Bugs

    [Sub-condition]If Bugs overlaps Vermin:[Action] spawn Splatter