Fib's Forum Posts

  • Great execution and marketing! Your game looks legit. I wishlishted it ;)

  • Your game looks legit. I love seeing C3 games of a higher quality. Wishlisted :)

  • quick question, why are you trying to use DXT instead of just using a background image?

    Because a sprite or tiled background is not compressed on the GPU. So a single 4K texture would take up like 90MB. This only makes sense for high resolution games where all the backgrounds are unique from screen to screen or level to level. Which means no repeated elements. I.e. you create an entire level background in a single photoshop project and export the layers as is. So tiled backgrounds and tilemaps are out of the question.

    while unity can compress the hell out of them, you can use png compression on your exported spritesheet once exported like tinypng etc... just make sure the size of the spritesheet doesn't change, you can bring down a 5mb to 100kb or less if done right.

    I'm not talking about compression on disk. Yes png files are great for low disk size. I'm talking about the texture being compressed on the GPU so the memory size at runetime is lower.

    having a 18mb 4k resolution background image sure is cool if you run it on a 4k monitor and im not talking about the 1920x1080 monitors that claim to be 4k... but an actual 4k monitor... that is 160cm wide or larger (also if you don't have a 4k gpu card, and a monitor/tv to be able to run 4k the detailing is pointless to have), if you do your game for majority of players a 1080p texture should be sharp enough to offer the quality and the detail needed. Mobile wise, you don't need textures greater than 480p.

    I'm not talking about screen resolution. I'm talking about the size of the texture. If your screen resolution is 1920x1080 and a level background is 4096px wide, then you would obviously have to scroll the screen to see it all.

    i just don't get the convoluted way of doing a simple replica of the game you mentioned. it looks 2d to me, no need for 3d stuff, but just the illusion of 3d, the player won't care that much if your gameplay is great.

    Also I'm not talking about making a 3d game. DXT has nothing to do with 3D games. Sure it was developed around the time 3D games got super popular so artists could continue pushing the limits. But DXT is simply a compression algorithm. It can compress a 4x4px texture or a 8192x8192px texture. The point is that the GPU can efficiently unpack them at runtime, regardless of 2D or 3D game.

  • 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.