Fib's Recent Forum Activity

  • I see. Thanks for the insight Ashely. I agree about clean pixel art games, you definitely don't want to do any lossy compression there. But I thought it might allow users to create higher resolution 2D games in C3 without hogging so much memory. Like Machinarium which has unique backgrounds for every screen. Almost zero screens have repeated elements.

    I got inspired by the video in the link below. It's a guy making a really high resolution 2D game in Unity. He uses like 4k textures even for simple background/foreground decorations that are 18MB each. But Unity can compress them down into less than 200KB in GPU memory using crunch compression (a variant of DXT5 algorithm). So yes, it's lossy, but for really high resolution stuff it doesn't make that much of a difference in quality, but the memory size is significantly lower.

    Having that feature could attract more professional artists to C3 if they know they don't need to sacrifice their vision to fit memory constraints.

    https://youtu.be/cqd1u_dfrkc?t=545

  • I was just learning that textures can be compressed on the GPU. And that the GPU can decompresses them efficiently at runtime. It appears it can drastically reduce GPU memory, so that much larger textures can be used than normally wouldn't be possible.

    It looks like WebGL supports them: developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Compressed_texture_formats

    I was wondering if C3 supports these types of textures? Or ever will in the future?

  • I don't understand the motivation behind this request. I can't think of a single game engine that renders svg in their runtime (the only exception is real-time text rendering, but that's not technically svg, just a similar process).

    The process in any major game engine is to build art in a vector graphics program like inkscape or illustrator, then export it as a png (rasterize it) to whatever resolution you want. The svg file is just saved off as a source document. You can still get very crisp looking art, especially if you export it at 2x the target resolution. That way when it's scaled down it still looks amazing.

    What's the issue with that?

  • Thanks for keeping this alive. It helped me tremendously when launching my game on Steam. I'll probably have to reference it again for my next game too.

  • I don't know the exact performance impacts, but it's basically a trade off of memory usage vs computation time.

    If you flip the tiles on the x/y axis you are adding computation time because the gpu/cpu has to perform the flip operation at runtime, but you reduce memory size because tileset image is smaller.

    If you don't flip them and just create extra tiles in the image then you are adding to memory because the image is bigger, but reducing computation time since there's no flip operation to do at runtime.

    So it's really up to you and your goals. If your game runs at 60fps when flipping the tiles then it might be better to save on memory.

  • What should the note say? "If your math is wrong then some mathematically identical angles will be treated incorrectly"?

    I already stated it in my first post. "...note that the "AngleOfMotion" property is automatically wrapped between -180 to 180"

    I'll give you an example of what the manual page could say. "Note that this angle property is automatically wrapped between -180 to 180 each frame."

    Also I'm curious to know if my screenshot where I use "Is between angles" is the proper way to do it?

  • It will be years before Steam is overtaken. Players will not just instantly stop using Steam. Many players have hundreds of games in their library (I myself have 60, which is tiny for most players I think). It's very easy to open up Steam to browse your library and then pop over to the store to see what's new.

    The advantage that Steam has and will continue to have for a long time is the number of players browsing the store (organic traffic) per day. When a dev puts a game on Steam they automatically acquire a massive audience, which if their game is attractive enough they have a chance to convert them into paying customers.

  • I got it working using "Is between angles" system condition.

    I'm just noticing inconsistencies with how C3 wraps angles. Sometimes it wraps between 0 and 360, the bullet angle of motion wraps -180 to 180, and sometimes there's no wrapping at all.

    IMO it's worth noting these inconsistencies in the documentation.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm very confused. It seems like 2 people are trying to tell me that C3 wraps "AngleOfMotion" between 0 to 360. But the C3 debugger proves that the value for the bullet's "AngleOfMotion" property is wrapped between a range of -180 to 180 degrees. So if you want to compare "AngleOfMotion" in any way you need to know that, or your comparisons won't work as expected.

    Asking a feature request

    You can maybe tag Laura_D or maybe suggest here:

    Link: construct3.ideas.aha.io/ideas

    I'm not requesting a feature. I'm asking that a piece of missing information be added to the documentation.

    Laura_D What do you think? Should this note be added to the documentation for bullet angle of motion?

    The thing is, the Construct Engine doesn't take input angles as raw data. It always processes it first and converts it to radians, then to angle. That is recommended and users too should always use either System Angle Comparators like the Is Between Angles or make their own calculations from degrees to radian then back to an angle within a selected degree scope.

    Yes the angle comparators are great, but if you're comparing a bullet's angle of motion property you still NEED to know the angle wraps between -180 to 180 to compare correctly.

    It actually doesn't wrap the value from between -180 and 180

    Yes it does.

    If you dl and run this c3p file in C3 you can play with it yourself. Run it in the debugger, pause it, then start plugging in values into the "AngleOfMotion" property.

    dropbox.com/s/dt3worrdtd56u8m/bullet_angle_example.c3p

    This gif shows me doing that exact thing with the above sample project.

  • ... and it really does go from 0 to 360. It's just that the expressions return values based relative to zero rather than 360.

    I'm not sure what you mean. You can definitely input any value into "AngleOfMotion" but the runtime engine will wrap it to -180 to 180. For example, if you input 270, the debugger will show -90.

  • This happened to me a few weeks ago.

    When you export to NW.js make sure the "Minify script" is UNCHECKED. That's what worked for me.

  • I can tell you're angry but nothing will be fixed unless you give them some details. You should tell them what browser you're using. Also are you using it on desktop or a mobile device?

    I use C3 almost everyday and I hardly ever experience crashes. I've only had like 2 crashes in the last 3 months.

Fib's avatar

Fib

Early Adopter

Member since 19 Jan, 2012

Twitter
Fib has 3 followers

Trophy Case

  • 12-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • x4
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x5
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

19/44
How to earn trophies