> > Hello I just gonna ask for pure optimization questions.Is it possible to render not in 640x360 resolution but something smaller like 1/4 of that because I need really long rays for some places due the fact its kinda open world kind project. I saw in your teasers that you have textures on floor and ceiling so if its plugin or something else? Will this engine transparency? Because if will then I could use just walls for roads in my project.

> >

> > Thanks.

>

> You can basically lower the project resolution and tell via global variables to use fewer rays, e.g. 320 px. Therefore you could utilize longer ray distances. The key performance boost is to test against fewer instances. The C2 version uses sprites as walls, and you have to test against each instance.

> The C3 version uses a single tilemap object (as showcased in the Youtube videos), which is a single instance. With some clever math figuring out the texture and wall angles, this means a massive performance boost.

>

> The floor and ceiling textures are not raycasted. In fact, they are rendered through sprites with the mode7 effect applied, then more or less correctly altered through player position and angle.

So using Mode 7 I could create floors. OK I have plugin and effect but in video is this repeated texture or one large? because for creating road like effect I'll need use large texture or chunks of said texture? And how proper use that effect because I kinda tried but if I set it as one its just white floor or just flys in very quick speed, anyway mode 7 for floor.

The best bet is to use a single big texture. You have to flip the image / rotate it though, as the sprite gets transformed by the mode 7 effect.

Also:

You have to factor in the players viewport angle.

Therefore :

mode7 x: Player.X / scrollingfactor + cos(Player.Angle)

mode7 y: Player.Y / scrollingfactor + sin(Player.Angle)

scrollingfactor is related to player viewport height and screen resolution / mode7 object height and has to be tweaked.

Also keep in mind for FPS purposes, the horizon line has to be at Y viewportheight /2.

Hello I just gonna ask for pure optimization questions.Is it possible to render not in 640x360 resolution but something smaller like 1/4 of that because I need really long rays for some places due the fact its kinda open world kind project. I saw in your teasers that you have textures on floor and ceiling so if its plugin or something else? Will this engine transparency? Because if will then I could use just walls for roads in my project.

Thanks.

On transparency: Unfortunately, the engine to date cannot render (semi)transparent walls effectively. That would mean, for each ray, you would have to test against walls until the ray hits a wall that has no transparent texture component, then stack each transparent wall and render it to a, for instance Paster instance, including the last hit wall which has no transparency. This is not feasible right now with C2/C3 plugins and would require a plugin to be written from scratch. Again, time is of the essence.

The semitransparent components shown in the Youtube showcase are composed of striped sprites spawn in the correct order, e.g. the gate style textures you can see before doors, the laser fence, etc.

Again, while this works in principle, it takes a heavy toll on the engine performance. I have yet to figure out a clever way to create and render these walls at runtime.

Hello I just gonna ask for pure optimization questions.Is it possible to render not in 640x360 resolution but something smaller like 1/4 of that because I need really long rays for some places due the fact its kinda open world kind project. I saw in your teasers that you have textures on floor and ceiling so if its plugin or something else? Will this engine transparency? Because if will then I could use just walls for roads in my project.

Thanks.

You can basically lower the project resolution and tell via global variables to use fewer rays, e.g. 320 px. Therefore you could utilize longer ray distances. The key performance boost is to test against fewer instances. The C2 version uses sprites as walls, and you have to test against each instance.

The C3 version uses a single tilemap object (as showcased in the Youtube videos), which is a single instance. With some clever math figuring out the texture and wall angles, this means a massive performance boost.

The floor and ceiling textures are not raycasted. In fact, they are rendered through sprites with the mode7 effect applied, then more or less correctly altered through player position and angle.

Colonel Justice do you have a c3p files about this ray cast method? Can you share this for construct 3? Thanks.

Still working on it, I'm having not that much spare time for the last couple of months, business and private-wise, so there might be a c3 example in some time, covering the basic methods.

The C3 version also is using a different raycasting method which eliminates the distortion artifacts you see in the C2 build. Reason is that I was following the Permadi method, which is not built on vector math, which you should use.

Hello again I fixed problem with walls they now render but wonky.

and in middle they look like one side is further than other.

Thanks in advance.

This looks like either math is wrong or a pixel rounding issue (wall render stripes being not integer widths).

Which files do I have to look at in your shared folder?

Consider my reply before:

You have to factor in the players viewport angle.

Therefore :

mode7 x: Player.X / scrollingfactor + cos(Player.Angle)

mode7 y: Player.Y / scrollingfactor + sin(Player.Angle)

scrollingfactor is related to player viewport height and screen resolution / mode7 object height and has to be tweaked.

Also keep in mind for FPS purposes, the horizon line has to be at Y viewportheight /2.

This is because the effect code is not properly written for C3. It will consider the whole spritesheet where the texture is packed in.

I used to work around this by using 1024x1024 textures for the mode7 effect and then setting the max spritesheet size to 1024 in the project settings. This will ensure that the mode7 texture is always the only texture on a spritesheet.

construct3.ideas.aha.io/ideas/C3-I-770

Backed with +3

I would check conditions inside the damage function, and then launch animations subfunctions whatever accordingly.

My experience is that if you funnel everything through a damage function, you have a single point were to debug later on.

Best example is the classic of the player being alive with negative HP. Not saying that it happens in your game but in general. To prevent this from happening, you have to put an event somewhere in your code that checks if the player health is 0 or below. Then do stuff. Not only do you need to put it in the right place in the event order, but it will get called every tick even if not needed.

A better way would be to check it only when needed, and that is inside the damage function, because intrinsically the function only gets called when needed (mainly collisions, overlaps).

The "downside" is that you should let the player only lose health through the damage function then.

I played your example a couple of minutes and didn't seem to run into any problem but again, maybe I was missing a certain constellation that makes this happen. Overall I would vouch you go with damage function generalization. E.g. also do the player damage stuff with progress bar from there.

Please share a sample c3p that we can work with together.