CairoCreativeStudios's Forum Posts

  • tgeorgemihai, Making a c++ compiler in Javascript is perfectly possible, but difficult.

    "A compiler is a special program that processes statements written in a particular programming language and turns them into machine language or "code" that a computer's processor uses."

    Javascript can be used to program a compiler just as easily as C++/C can. The problem is that it's very difficult to do, and Scirra wouldn't be capable of such a task.

    xanxion, asking for more stable exports from Scirra's small team is a waste of time. They need more money and workers before they'll be capable of performing such a large task effectively. Although I do agree that the subscription based model is not good when combined with an engine many of us have already bought, I'm hoping that the money they're capable of making with this update will allow them to do just this, and meet the demands of the users.

    It's probably best to assume that this high price is being asked because Scirra wants to be able to include the features their users are asking for, which means they will have to grow more first.

    • Post link icon

    , oh that's my bad. I thought you were arguing the quality of Construct as a whole, and Scirra's HTML5 goals. I would also agree that C3 is flawed, but because of the licensing, not because of it's exports. Either way, this isn't the kind of engine that should require that kind of licensing, unless it becomes open source.

    If it follows in Epic's shoes, by accumulating a lot of money from a subscription based method and then later releasing it as open source, I would be all for it. Otherwise, the convenience of it's use isn't worth the money I'd have to put into it. I use Construct 2 on a daily basis, and I'd like to do the same with C3. Really though, C3 just seems like a portable/multiplatform C2. :\</p>

    • Post link icon

    , I'm out of the loop here, but if you don't like C2, why are you even here in the first place? I'm hoping that was a joke on your part.

    C2 benefits from being cheaper than everything else. It works great, I've never ran into any more problems with it than I have with other engines. Especially Unity.

    Game Maker and UE4 are both very well made engines. Eiher way, if canceling a game is something to complain about, you either didn't plan out the development of your game at any point, or you're wasting your time developing games altogether. You should be learning how, rather than actually making them, if you don't know the limitations of almost all engines available to you.

    I could list hundreds of free game engines' limitations to you right now, and even with the experience of knowing them all, I still come back to C2. So, I personally see no reason for Scirra to change.

  • suzannegrey, well, obviously that's ultimately up to you. The map editor is built into the game, so anyone can participate. This also makes modding the game possible too, so either way, it'd be a waste of nobodies time.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • suzannegrey, I'm going to be running a kind of "dev audition" where I'm going to be releasing the game with the level builder/scripting&storyboard interface and determine who to have join based off that. It will be relatively easy to use, and uses JSON format/multiplayer building so people can build projects together very easily.

    Whenever the beta is released, this will come with it. I'll let you know when that time comes . It will be a few months.

  • Artpunk, When remaking the Jump-thru behavior from scratch, one would have to check, for each solid object, if the player at a Y of -1 is overlapping the solid object. If not, enable collisions with that object.

    In this case, one could simply use this check to, rather than enable/disable collisions, add if player is falling, and if so, set vector Y to 0.

    The fact that this is happening, though, points to a problem with how you've implemented controls, positioning, collision masks, etc. It could be anything, but this kind of functionality doesn't happen naturally with platform and jump-thru behaviors, it certainly isn't a bug as I've never seen this happen before.

    EDIT: make sure that when you use the event I mentioned that you're also adding a condition of player is overlapping the platform at y offset of +1, or the player won't be able to fall.

  • Scofano's suggestion will work.

    Jazz813, you'll need to ether share your CAPX so we know what you're doing, or better define it.

    You'll need specific positions for each placement of the sprite, which I'm sure you know by now. If you're going to make a layout for each frame of the game, you'd need to create a layout for each possibility in-game, which is incredibly complicated, and a total waste of time.

    Also, if English isn't your native language, please include your native language, so we might be able to be of more help.

  • I'm surprised that nobody with actual Multiplayer experience has commented on this.

    The multiplayer functionality in Construct 2 is perfect. It's some of the best multiplayer programming you'll find and uses all modern multiplayer coding methods.

    The solution to your problems ISN'T in not using Scirra's multiplayer examples as a starting point. Look at them, learn proper input prediction.

    Use Construct 2's interpolation

    Use subtle extrapolation, through peer states (stored within byte values)

    Slow it down, allow the host and peer time to make sure they're synced up before important events

    When sending data back and forth, don't use strings in the middle of gameplay. Use bytes, or byte sized values. Not sure if it's Construct 2, Javascript, or the underlying C code, but any whole number within 256 is already equal to the byte equivalent.

    Remember that, because you'll be able to use that to your advantage often.

    Run cell checking for player characters. Basically, what I mean by this is divide your layout into 256 evenly sized sections, or cells, and sync the player's current cell position to the host.

    Having both values, the host can interpolate (slightly), pulling the player closer to that cell's position. This will make up for some of the positioning latency, even if just a little.

    OPTIMIZE! Not just your multiplayer programming, but everything else to. Once one peer suffers from poor performance, so does everyone else.

    Round synced positions.

  • X3M, that's wrong. You can easily make a forum using C2, Ajax, and PHP.

    You can even make the server side code rather easily in C2 using these plugins and exporting to Node Webkit.

  • For anyone coming to this post looking for a good answer, my optimization tips for you if you're working on a project like mine is:

    Posterize EVERY detailed background/object in the scene. I only pre-posterize my backgrounds, which saves a lot of memory, by significantly shrinking the size of each visual object.

    https://www.scirra.com/blog/ashley/14/h ... cells-work

    USE RENDER CELLS. The two towers in the game's prototyping map are quite large, and impact performance. Pairing TileMaps with Render Cells for the map's layout is the best idea. The towers, for example, are sprites. They will only be drawn when the players are close to them if I enable Render Cells on the layers.

  • Kyatric, Ah, okay, thanks for sharing this, I couldn't find it through searches for some reason. Very helpful. I did forget to include the HUD timesets in my description, but this is all I really needed to know, thanks!

    I'd assume my only performance issue is the backgrounds, due to memory usage. Thanks!

    Also probably the HUD tilemap now that I think of it.

  • When reading https://www.scirra.com/manual/134/performance-tips and other performance enhancing posts, it's hard to pinpoint exactly why my game is lagging due to draw calls. I only have 3 tilemaps being draw at once, each of which having relatively large tiles in comparison to the screen. The amount of tiles drawn at once never exceeds 100, and hardly exceeds 50.

    I'm trying to find why the draw calls could be affecting performance with such an impact, as the profiler puts that at the top with 50%. This might actually be wrong though. I believe the actual problem is the amount of unorganized for loops running in the project.

    It's also possible that the performance issues are specific to the computer I'm using, as the specs aren't that great, and I experience lag in almost any game made within the past 10 years, if not rendered with DX11.

    Anyways, if anyone has any more information on when calls to draw are done, that would be nice. If need be I'll create a link to the CAPX here, but you can click the gif below to go to the game's page that includes the CAPX.

    • Post link icon

    Zebbi I meant I'd make an exporter to Fusion from C2, allowing C2 to take advantage of Fusion exporters.

    As for everyone else replying to this thread, I'm not going to be answering anymore. My answers for your questions are as follows

    Q. Why do it?

    A. Because I can. It's good for my portfolio, and it's just for fun. I'm not making any promises, don't expect anything of it. I came here with a simple question, that question has been answered.

    Q. Why, when C3 is coming out, would you make a C2 exporter?

    A. I highly doubt that the XML project file structure will change much. It's incredibly unlikely, because the current project file structure is very solid and useful. I said that in my original post.

    Q. Why would you waste your time if you don't see it going anywhere?

    A. If you're going to sit here and tell me you don't have hobbies, you're lying through your teeth. Maybe you game in your free time. I program in mine.

    Q. How would this make a good portfolio piece?

    A. Because, it requires a complete rewrite of the Javascript engine powering Construct 2. That's a big feat, not one I will ever say I can accomplish, but one that would definitely look good on a resume, because it's essentially the same as writing one's game engine, the difference being that Construct 2 is the interface, and one I did not make.

    Q. --

    A. I've probably already answered your question. Read. -.-

    Anyways, I've asked to get this thread removed because I'm done answering questions right now.

    • Post link icon

    Zebbi, wow...

    Man... You probably shouldn't have told me that, I might not even take time to make a C exporter now, might just make a Fusion exporter.

    • Post link icon

    , Working on this as a hobby, not as a legitimate, full time project. I'm focused on developing my game right now, not on making this. You also have to consider the fact that making it a community project is essentially the same as forming a team, the difference being the fact that I'm not held liable, and nobody else working on it is.

    Maybe if I had more money to spend, I'd hire programmers to work with on it. But, for now, it's simply just for fun.

    R0J0hound, Haha I definitely don't have a one year time frame! I'd have to put my game aside to do that, which wouldn't be practical in the long run, unless I made people pay for it. Which I wouldn't. I was simply saying that last year I'd posted about this topic, saying illogical things, not knowing what I was doing.

    The features I plan on implementing will be on an as needed basis after the core engine is rewrote. Which means updates will be slow and inconvenient if I'm the only one making them. I'm hoping that people understand this and don't get so excited about it. I'm not making any promises as to it being feasibly useful. At least, though, it could serve as a starting point for the future of Construct, and my career as a programmer.

    Eisenhans, Reprogramming Construct 2 in C is the same as making my own engine, the difference being that the interface is already there.

    Reprogramming Construct 2's javascript engine in C IS making a new engine. You can't just copy over Javascript into C. An exporter in Construct 2 does NOTHING aside from structuring the project properly for packaging with a specified tool, such as Intel XDK.

    On my portfolio, it wouldn't read as "programmed an exporter", which really would be a waste of time, not because of feasability, but because of the reason you mentioned. It would read as something along the lines of "Reprogrammed C2's Javascript engine in C, for native compilation".

    Also, you have to consider the importance of C as a language. Even thinking that this kind of thing could be simple shows the lack of knowledge required to do it, and if someone won't hire because of that kind of thinking, they don't know what they're looking for and most likely won't pay well. So, I'm not worried.

    Additionally, the only limitations of using Construct 2 to do this is the fact that Construct 2 was made in Javascript. Though, Construct 2 has EVERY FEATURE any 2D game engine should have, and more. So, I wouldn't be limited by anything other than my own experience as a programmer.