Відео

@@LeoOno Hi man!! Yeah, it's been a while. But it's not that I'm not working on anything. I have two projects in progress. The thing is that neither of them are in an interesting/finished enough state to justify a video.

Gracias, loco!!

If it is I managed to create a simple pixel by pixel rendering loop with gdi and c#. But managed to get it to run in parallel. Which I was told was not possible. Anyways always interested in see people's games built with their own game engines

Hi, man! Yeah, it's all good old fashion C# .Net Framework GDI+

Thanks, man! Let me know when you upload a video of your engine so I can check it out! By the way, although my engine allows plotting pixels, this particular video is done entirely with a standard GDI+ TextureBrush.

Hi, man. Thanks!! What have you been up to? It's been a while since your last upload.

@@adrikriptok7225 sorry for the late reply! i wasn't able to do much, but recently i tried to revisit light mapping, something i wanted to do a long time ago. i've only recently started to understand it better and just posted a video :) And how about you? Are you trying to finish this game? I’d really love to try it out soon here!

@@LeoOno I wish I could, but no... I haven't touched it since this upload. I've been very busy for a while with a lot of work, even on weekends...

Thanks, man! I know the effect can still be improved, and I always get great ideas from the comments section (like the improvements we talked about in my environmental mapping video, although I never could make it work perfectly for nearly horizontal polygons that reflect the 'poles' of the skybox), so I just posted what I had. And yeah, that soundtrack is ESSENTIAL for a video like this!

@@adrikriptok7225 oh I wanted to ask, is this terrain engine similar to the one Leo did?

Hi, man. If you're talking about this video ua-cam.com/video/d1MVZukvP_w/v-deo.html, not really. In Leo's voxel engine, you have a predefined max depth by a fixed number of scanlines. Most voxel space engines work like that (it all comes back to Comanche). With this approach, the rendering is much more stable, but you cannot have the camera too high because the "end" of the rendering space would be too apparent. You have to keep the camera close to the ground. When I made this voxel engine, I thought about using that approach, but I wanted to be able to raise the camera over the mountains and still be able to see the terrain to infinity (don't know why, now, it seems like a pretty stupid decision, but here we are). So my algorithm is the same as painting a flat texture, like Mode7. That's why far back there's a lot of flickering. But I can have the camera as high as I want and still see the terrain keep repeating until infinity. I could reduce the flickering by sampling the terrain as if the "mode7 plane" Z = 0 were far lower than the camera (let's say Z = -50), but it would obviously harm performance. So I would also have to set a "max depth" to compensate, and then I'd probably get a result more like Leo's.

​@@adrikriptok7225 Oh ok. So it's like rendering the mode7 plane, except for each pixel on the plane you calculate which cell of the height/color map you need, and then render a vertical column with that height? And the height would be divided by Z or something?

@@fuzzycat3651 Exactly! In a Mode7 plane, you just sample color, but in this case, it's color and height. Then you make the necessary calculations to plot the column correctly (dividing by the distance to the camera, adding or subtracting the camera height. You know, the usual).

I'm using Bryce 5 now. It's a bit old (and the terrain editor is limited), but the terrain fractal algorithms are great. Sadly, the process has a few problems. For instance, exporting the heightmap works perfectly, but the textures don't look right and don't have shadows, so I have to render the terrain with the camera on top and save the result as a 'texture.' However, it can only render in 4000x4000, so I have to stretch the texture to 4096x4096 to match the terrain. It is very tedious, and the results are far from perfect, but I'm just having fun after all.

@@adrikriptok7225 I remember Bryce. I don't think I ever used it. I can see it makes fractal terrain. I wonder if it has erosion effects. I'm guessing it does, and that would add a lot. The 4000x4000 max resolution is curious. Does it make seamless terrain (infinite wrap)? How are you adding lighting/shadows to it? Lighting is fairly easy to do, but shadows needs more effort. This is an area GPUs would help.

@@JDoucette Yeah, it has erosion effects and works pretty well (I think, but I'm not a geologist). The shadows are added by Bryce. Maybe I wasn't clear enough, so I'll try to explain again: Bryce has an "export" option, but it exports the terrain (the 3D model) and the texture without any light or shadows, so when you add the object in a 3D environment, it is affected by the current ambient light (which makes perfect sense). But for a game like this, I have to do it manually. For example, the height map is easy: I just copy-paste it from Bryce to any drawing software and save it as a PNG. That's the easy part. For the texture, in Bryce I have to position the camera on top of the terrain looking down (trying to match the corners of the terrain with the corners of the render area) and then render it (with shadows and everything). That render is a maximum of 4000x4000, so I have to stretch it to 4096x4096 to match the height map exported previously. I hope that's clearer. And no, there are no seamless terrains in Bryce that I know of. And even if there were, the way I'm rendering them probably wouldn't look right anyway.

Thanks, but the water (and the shimmering) is something I cannot take credit for. It's just an animated texture I took from one of the Div Games Studio examples. The flickering, sadly, is because I'm not really using the same algorithm as Comanche. I'm doing something different that depends too much on the resolution. It has pros and cons, but in this map specifically, it is very noticeable because of the high contrast (both height and color). The previous level was more uniform and soft. I didn't know the original Voxel Space used mip-maps. I've thought about it, but I can always add them in the future if I don't find a better way to improve the visuals. My maps are 4096x4096, but they don't tile infinitely like the ones in Comanche (yet). You can find the map in my games repo. The code is not up to date, but I just updated the texture and height maps if you want to check them. github.com/adri-kriptok/games/tree/master/Kriptok.Tehuelche/Scenes/Map00 The 'depth cut-off' effect is because those mountains are beyond the horizon (the horizon created by the curvature). The terrain is drawn front-to-back, so I start rendering off-screen and don't think about the horizon when drawing. But the reflections are rendered back-to-front, so I have to give it a 'starting scanline,' ergo, I start rendering reflections at the horizon, ignoring what can be beyond (It's clear I don't have everything figured out yet). About the Z-buffering: it's not that proper. The terrain occludes the objects, but the polygons don't share a 'z-buffer.' All the polygons of each object are drawn together (sorted by the painter's algorithm), except the ship, where every polygon is independent (required because of the size and the superposition with the turrets). Having a proper Z-buffer would drag the performance.

@@adrikriptok7225 You know the cause of flickering very well, as I've experienced both. At extreme height changes, a ray can pass through a corner, and make it even worse. Mip-maps are your first order to correct, but it doesn't fix large changes in color/height from voxel to voxel. To solve that, you'd need to step through the voxels during the ray cast at a smaller step, or even compute where they end (like you would in Wolf 3D, if each voxel was a tile in a room).

@@adrikriptok7225 I don't think you have curvature, do you? So you just cast the ray to a set distance, then stop? In my original 1995 VGA engine, I also didn't have mip-maps, but I stepped larger in the distance, which causes more flickering, but allowed me to render further in the distance with the same work. However, mip-maps would've reduced flicker, and reduce caching issues -- speeding up the engine.

@@adrikriptok7225 I "cheat" in my software engine, since the GPU naturally gives me a Z-buffer. Since our algorithms naturally have a Z buffer, I give it to the GPU. Therefore, my sprites (or your polys) would render correctly, effortlessly. However, I devised a software solution without having a Z-buffer which I was going to implement (but never did) in my 1995 VGA engine: you only need to record the height of each hill -- just as I do in my Pseudo 3D road engine. Then that's your clip range (like the edges of the screen). But it differs per-column, so render your sprites (or polys) per-column. :)

@@JDoucette That's what I'm doing. While rendering the terrain front-to-back, and when I have to render an object, I calculate the 2D bounds of the object (the rectangle) and compare it with the current height buffer. If it is totally visible, then great, I save it in a new list and continue. If it is not visible at all, I do nothing, and if it is partially visible, I save it int the same list, but also save the status of the height buffer (for the horizontal bound of the view). Then, when the terrain is done, I just render all the views saved in the list, occluding the bottom part when necessary.

Thanks!!

😄😄😄😄 Se agradece el entusiasmo, pero le falta tanto...

@@adrikriptok7225 por que esta buenisimo.

Gracias, loco! Igual el movimiento tiene un problema que todavía no pude corregir, y es que girar quedó atado al frame rate. Cuando se arrastra un poquito, se nota, y gira más lento. Pero bueh, como varios proyectos usan el mismo código, tengo que entrar con pinzas a tocar ahí.

@@adrikriptok7225 calcular el deltaTime entre frames no te funcionó?

@@LordFers Sí, sí. Para casi todo lo que es movimiento lo uso. (Por cierto, recomiendo fuertemente este video sobre el tema: ua-cam.com/video/yGhfUcPjXuE/v-deo.html, mirátelo si podés, está muy bien explicado) El tema es que cuando programé la interacción del mouse (uso el mouse para girar al helicóptero y la cámara) no supe cómo incorporarlo (o me olvidé, ni idea), y como la mayoría de las veces no se nota, lo dejé así... durante años... Y bueh...

Thanks!!

Oh... that's the only thing I can't take credit for. It's an animated texture I took from one of the Div Games Studio examples from back in the 90s.

Thanks, man. I probably make an improved version soon (check Harrison comment in this video, where we discuss what I did wrong). But I'll probably still have a problem when the normal of the face is too vertical.

I imagine you could use a skybox with the limiting factor being: you need to handle edge cases when linearly interpolating texture coordinates that run across the seams of the skybox. But at least with a skybox you wouldn't have the problem of distortion near the poles. On the other hand, you could probably just linearly interpolate (and re-normalize) vertex normals across each triangle and simply cast a ray into the skybox with that normal for every pixel, since ray-cube intersection only requires division instead of arcsin, arctan etc. This would incur one division per pixel which isn't terrible since you're already doing that when inverting 1/z.

@@fuzzycat3651When Leo first asked me about this subject, I thought of a skybox too, but I think it would be changing my current problem (the poles) with a greater one (the edges). I already fixed the reflections, by the way, using the approach we talked about, and it looks great. And I kinda have an idea of how to fix the poles: I just have to find a way of knowing when the face is gonna get the coordinates messed up (when the normal of the face is near parallel with the vertical axis) and just split the triangle in three. I don't have evertything figured out yet, but I'm pretty sure I can do it.

@@adrikriptok7225 That's a good solution! I'm sure it will work.

@@fuzzycat3651 @adrikriptok7225 all of these are very interesting solutions, thank you :)

Thanks, man. I mostly try to keep videos short so you don't get bored, and used to refer to my repo for coding questions (back in 2016, when it was pretty basic stuff). Then it became so big and complex (with layers and layers of inheritance) that it was kind of useless, since some cool stuff required multiple layers of code and it was hard to follow. So I created the games repo (github.com/adri-kriptok/games) just to have the more "complete" projects or tests that I show here, but I eventually didn't have the patience or responsibility to keep it updated either. I'm lazy. About the Discord server, I think ​@undefBehav (Emre Akı) suggested something like that some time ago, but neither of us used Discord or Telegram (and I, at least, still don't). I think it would be cool if we could get a lot of people on board, but since I'm not used to it, I don't know how it would work.

Exactly. Although, now that you mention it, I don't think it would be that hard to fix it using some rays from the camera. And maybe it would help me solve one of the problems I'm having.

​@@adrikriptok7225You mean just doing regular "mathematically correct" reflections or something else?

Yeah. It would be like ray tracing, but casting only three rays per face from the camera (one for each vertex) and reflecting them to the background sphere. I don't know the formula yet, but I'm pretty sure chatGTP does.

@@adrikriptok7225Lol! I'd put my money on chatgpt giving you the wrong formula

@@adrikriptok7225 > It would be like ray tracing, but casting only three rays per face from the camera (one for each vertex) and reflecting them to the background sphere. I don't know the formula yet, but I'm pretty sure chatGTP does. This is the exact same approach I was trying to explain in my other comment. I guess I should have made it explicit that I imagined doing that (calculating a vector between the camera and the polygon vertex) three times, once for each vertex of the triangle. 😅 That's why I was actually confused about the problem you mentioned regarding the sizing of the background sphere. Come to think about it once more, that shouldn't be an issue as long as you calculate those reflections correctly, should it? 🤔

Thanks! Although I know the pretty backgrounds make it look much better and more interesting than it really is.

Hi, man! Thanks!! It is simpler than it looks. The shape is just a common textured shape. The difference is that instead of using always the same UV coordinates, each face recalculates the UV mapping to "reflect" the environment. In reality, there's zero reflection involved and the shape doesn't know about the background. It's just a basic polygonal shape with a background texture applied. How to recalculate the UV coordinates each frame to display the "reflection" is the interesting part. In my case, I'm adding a normal to each vertex (as the average of all the normals of the faces that uses the vertex) and then using those normals to sample the UV coordinates of the texture that has to be displayed (the background has to be designed to be sampled as spherical coordinates, obviously). This is usual spherical mapping, that can be used for backgrounds too (without multiplying by -1f): private TextureMappingPoint Map(Vector3F normal) { var phi = (float)Math.Atan2(normal.X, normal.Y); var theta = (float)Math.Acos(normal.Z / normal.GetNorm()); var u = (phi + MathHelper.PIF) * (-1f / (MathHelper.PIF * 2f)); var v = theta * (-1f / MathHelper.PIF); return new TextureMappingPoint(u, v); } There's a few problems with this approach in my case around the edges of the texture, but you should start with this and see what you get.

@@adrikriptok7225 So you intersect the “vertex normal” of each polygon vertex against a sphere which has the texture applied that is going to be reflected on the surface, that makes sense! So all that is involved is calculating the intersections of vertex normals against a sphere to be able to calculate the UV coordinates of the texture, is that correct?

​@@undefBehavExactly!! Here's where I encounter one of the issues: let's consider a scenario with only one polygon (where all the normals of the vertices would be the same). Consequently, when they intersect with the sphere, you would obtain identical UV coordinates for all three vertices (assuming you're calculating them, like me). I'm still contemplating what to do in that case. If the polygon is small enough on the screen, you could simply fill it with a single color. However, if you apply this approach to a large polygon, it wouldn't look right. Another idea I'm considering is to modify the normal by adding the vector of the vertex location (relative to the center of the figure) multiplied by a small constant. This adjustment might make it subtly noticeable, but it would generate different normals at least. Let me know if you come across anything interesting regarding this topic. I'm new to this too.

@@adrikriptok7225 ​ Hmm. That's indeed a nice problem to think about. How I imagined it in my head was an approach similar to that of Sonic R's. You calculate a vector between the camera and the polygon vertex, reflect that about the vertex normal, and intersect the reflected vector (offset by the position of that vertex) against the sphere. That way, due to how each vertex is positioned differently relative to the camera, I guess you should get different reflections (thus, different intersections with the sphere, resulting in different UV coordinates) for each vertex, even if they all share the same normal.

@@undefBehavBut in that case, you would get different reflections depending of the size of the "background sphere" you're intersecting with. And if it is big enough, you'll end up with the same problem anyway.

Thanks, man! And yeah, the environments are being render by the ray marching algorithm. It's like, imagine you've a ray casting engine, but your map is just 2x2 cells, and only one is occupied. Like this: 1 0 0 0 Then, you cast the rays, as usual, but you apply modulo to every coordinate by the size of the 2x2 map (let's say, every cell is 128x128 pixels, so you take the modulus by 256). The rays will only check for walls in that small area, finding the same walls over and over again. Then, the map will repeat infinitely. 1 0 1 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 That's basically it.

@@adrikriptok7225 it was a really easy to follow explanation, thank you! so that's why fractal :)

@@LeoOno You're welcome. I'm actually trying to create a scene like this with ray casting in 3D hoping that if the scene is very simple and enclosed enough, it can run at an acceptable speed. No luck yet.

Thanks, man!! I feel like parallel processing would bring a new set of problems, so I've been avoiding it. Regarding the lattice shapes: they complement the others. The last one in the video is the complement of the space with the 'infinite spheres,' and the same applies to the cubic one. For example, this is my code for the 'infinite spheres': protected override float Scene(Vector3F vertex) { vertex = vertex.Mod(256, 256, 256).Abs(); return vertex.Minus(128, 128, 128).GetNorm() - 64 /*radius of the sphere*/; } - "Scene" is the method that returns the next distance to advance to the next step. - "vertex" is the current position of the algorithm. - "Mod" applies modulo to every coordinate, creating an infinite repetition. For the 'infinite holes,' it is the same, but subtracted from a constant (let's say 100): 100f - (vertex.Minus(128, 128, 128).GetNorm() - 64); Then: 164f - vertex.Minus(128, 128, 128).GetNorm(); Finally: protected override float Scene(Vector3F vertex) { vertex = vertex.Mod(256, 256, 256).Abs(); return 164f - vertex.Minus(128, 128, 128).GetNorm(); }

Thanks, man! And yeah, it is a polygonal cubesphere. However, adding spherical texture mapping for backgrounds is on my to-do list. Maybe I'll tackle that next.

Yeah. If you check the videos I added as context in the description, using the GPU doesn't significantly impact performance. However, for software rendering, it's not looking promising. I still have faith that I'll find a way to optimize my code enough for it to be useful.

Naaaaah, no da. Es un bootleg, nomás, con gráficos sacados de otros juegos. Cuando subí el video del primer nivel al git donde tengo los proyectos más terminados, había subido una versión compilada también. Algún día actualizaré ahí.

Gracias, loco! Hacía rato conocía el concepto de Ray Marching, pero no lo había implementado porque realmente no lo entendía. Vi varios videos, pero en ninguno explicaba lo suficientemente claro el concepto. Y de repente un día cayó la ficha y lo entendí. Eso no significa que sea capaz de renderizar cualquier escenario a gusto, como fractales complejas, pero al menos tengo claro cómo funciona.

That's cool. Haven't you ported the code to your newer engines??

@@adrikriptok7225 The original old code was in Turbo Pascal for MS DOS, and the recent code was in XNA/MonoGame for Score Rush (and unreleased Duality ZF). I have not yet ported this to the new engine -- port is a strong word, but it's really a matter of me extracting it from the Duality engine and putting into the generic Xona System 8 engine. This will eventually happen, but far later on my list. Decimation engine will be ported first! :)

@@adrikriptok7225 UA-cam shows 2 replies, but I only see yours. I believe I replied already (from my phone) -- curious, can you see my response? I wonder why it is not showing for me.

@@adrikriptok7225 Short answer: original was Turbo Pascal, improved was in the Duality engine (Score Rush and unreleased Duality ZF), and next step would be to port it to the Xona System 8 -- my latest engine, which will be a foundation for all of my prior work to run within.

@@JDoucette Hi, man! Yeah, the same happened to me. I can see your response but only in the youtube studio. It's weird.

Oh, man, DIV was my childhood (and teenage years). Back then it was the only engine I knew, and I kept using it even well into the early internet era. Every game engine I've made was based on it. Mainly trying to replicate its simplicity while shedding its limitations.

Thanks, man! The level design is very different and much more complex than anything I've done before. There's a lot of "room over room", for example. I'm not 100% satisfy with it, but it's good enough. About path finding: No. I don't think it's the best approach for an FSP. If all enemies knew exactly how to get to you all the time, once active they would all gang up on you and most of the map would be empty. This way, enemies more or less maintain their place on the map design. And in an FPS you don't spend time watching enemies move around the map, but instead you look for them and kill them. However, it would be useful if you have human companions like in Daikatana.

@adrian oh you mean one on the top of the other? if so, the collision is in 3D, awesome :) ! about the enemies, get it, the movement looks really nice! i didn't know about daikatana game, will watch some gameplay videos later

@@LeoOno Nah, I wouldn't call it "3D". All the collisions with walls are resolved in 2D, but the selection of walls to evaluate collisions takes into account where you are in the map like it was an euclidean space. It would still work even if the two partitions occupy the same vertical space. I'm... probably not explaining it well...

Thanks man!! I don't think it will take this long to show progress anymore. The engine still has problems, but it is much more mature now. I also MUCH improved the level design process by building it in a common 3D editor and then translating it to my engine to set up textures and metadata. I even have a lot of work done I haven't shown yet. The T-Rex, for example, is already in progress.

@@adrikriptok7225 T-Rex sounds like he’d make for a great boss battle actually. :D Exciting stuff!

@@undefBehav That's the idea!! I have sprites for at least two big bosses: T-rex and triceratops. I wouldn't want to though, since in my head the T-rex should be impossible to kill; like an unstoppable force of nature. But there has to be something at the end of the game and that's the best idea so far.

Thanks, man!! Merry christmas to you too!!

Thanks! And yeah, everything you see here in my channel runs on the same C# & GDI+ engine.

Hi! GDI+ is a library with the basic tools .Net Framework uses to draw things.

Gracias, Lucía! Espero poder terminarlo algún día y no decepcionar a nadie!

Hola, Lucía. Ante todo, podés comentar en español si querés, yo hablo español. Esto es sólo un teaser, de un juego que estoy haciendo, pero le falta mucho todavía. Hay una versión subida en mi repositorio que se puede descargar y jugar, pero la verdad ya cambió tanto que no tiene mucho sentido. Además tenía algunos errores muy groseros. Espero para fin de año poder subir una versión jugable actualizada.

@@adrikriptok7225 ah vale! :D

@@adrikriptok7225 pero dónde lo puedo descargar?

Thanks, man! It's finally starting to take shape now.

hi @Adrian offtopic question: do you have an ideia how we can implement the mirror/metal/reflection effect using only affine texture mapping like in this video ua-cam.com/video/0vs6GarE0R8/v-deo.html ? I know how it can be done using phong shading but i was surprised when i saw it using only affine texture.

@@LeoOno Hi, man! What you're looking for is "environmental mapping", I believe. I've no idea, but in this video there's a basic explanation that may be useful as a starting point: ua-cam.com/video/WDJgeuoaSvQ/v-deo.html

@Adrian thank a lot! I can't believe i hadn't seen that video before, it gave me a very nice ideia how it works, but still, couldn't figure out if only 1 single image would be enough for top and bottom reflections ... ?

​@@LeoOno Well I think the best approach would be to use a full six sided box. Because you need to reflect from any angle and position of the camera. You could also use a sphere, with a coordinate change from cartesian to latitude/longitude to UV, but I don't think that's necessary. The box approach seems much simpler and more effective. Though, you would have a problem of what texture to use if different normals intersect with different sides... but in the sphere approach, you would have a problem if the polygon is too horizontal, because of the coordinate change to lat/lon... IDK. All this talking is making me wanna try it myself to see what happens...

Thank you! I've a very cool idea for the first appearance of the T-REX too, but I haven't started yet. I hope it ends up being as cool as I see it in my mind. In any case, at least I hope the Doom community realizes that we need more (and better) dinosaur Doom mods.

Nah, ojalá pudiera, pero es mucho. Apenas logro conseguir ratitos de tiempo libre para ir agregándole cosas y mejorándolo. Estaría buenísimo, la verdad. Hace rato pienso en hacer algún juego que corra en DOS nativo. Cualquier cosa, aunque sea un asteroids.

Thanks, man! It's a big project. I hope I'm able to finish it some day.

Thanks, man!! I haven't uploaded this version to the repo yet because I keep tweaking it. But I will eventually, as I did with the V0.1.

Thanks, man! I hope I'm can finish it some day. There's a lot of work left...

😂 Thanks man! It is an ambitious project. I hope I can finish it some day.

hi Adrian, i was reading some ps1 docs about clipping issues and it recommends to subdivide the large and near faces but couldnt find any examples. Can you please explain how you are doing it? is it just checking the distance or does it also need to take the area in 2d space in account? thank you 😀

@@LeoOno I've tried many approaches through the years, but the one that worked better for me, is to use the distances between the vertices. I use recursion, but if you have limited memory, so you should replace it with iteration. So, let's say I've what I call a "panel". A "panel" is a plane quad, at best drawn with only two triangles. No UV mapping per pixel, but defined by four variables: u0, v0, u1, v1 (u0, v0) t0 --------- t1 (u1, v0) | / | | / | | / | t2 --------- t3 (u1, v1) (u0, v1) So, after calculating all the usual stuff like back-face culling, light, etc (NO clipping against the camera needed). I call the "draw" or "render" method for that "panel". Then, it starts: // This is a constant you should twick to your needs. private const float minSizePolygon = 48f; void render() { // start recursion sending 3D vertices and UV info. fillQuad(t0, t1, t2, t3, u0, v0, u1, v1); } void fillQuad( Vector3D t0, Vector3D t1, Vector3D t2, Vector3D t3, float u0, float v0, float u1, float v1) { // this is why it wasn't necessary to clip before. if (all_behind_the_camera(t0, t1, t2, t3)) { return; } else if (any_behind_the_camera(t0, t1, t2, t3)) { // if anything is not visible, I split the shape. splitQuad(t0, t1, t2, t3, u0, v0, u1, v1); } else { // I project to the screen: var p0 = ProjectToScreen(t0); var p1 = ProjectToScreen(t1); var p2 = ProjectToScreen(t2); var p3 = ProjectToScreen(t3); if (none_on_screen(p0, p1, p2, p3)) { // if nothing is visible on screen, done. return; } else { // find the bigger distance (2D distances). var dH = Max(GetDistance2D(p0, p1), GetDistance2D(p2, p3)); var dV = Max(GetDistance2D(p0, p2), GetDistance2D(p1, p3)); if (dH < minSizePolygon && dV < minSizePolygon) { // if small enought => render to screen. blitQuad(t0, t1, t2, t3, u0, v0, u1, v1); } else { // if too big, split the shape. splitQuad(t0, t1, t2, t3, u0, v0, u1, v1); } } } } // Draw shape splitted. void splitQuad(Vector3D t0, Vector3D t1, Vector3D t2, Vector3D t3, float u0, float v0, float u1, float v1) { // here I'm calculating 3D distances. var dH = Max(GetDistance3D(t0, t1), GetDistance3D(t2, t3)); var dV = Max(GetDistance3D(t0, t2), GetDistance3D(t1, t3)); // here I use the relation between the distances. var dH1 = dH < 1f; var dV1 = dV < 1f; var dHV2 = dH / dV; if (dH1 && dV1) { // if it is small enough, and partially visible, I call simple draw. if (all_in_front_of_camera(t0, t1, t2, t3)) { blitQuad(t0, t1, t2, t3, u0, v0, u1, v1); } } else if (dHV2 >= 2f) { // split horizontally. var p01 = Average(t0, t1); var p23 = Average(t2, t3); var u01 = Avg(u0, u1); fillQuad(t0, p01, t2, p23, u0, v0, u01, v1); fillQuad(p01, t1, p23, t3, u01, v0, u1, v1); } else if (dHV2 <= 0.5f) { // split vertically. var p02 = Average(t0, t2); var p13 = Average(t1, t3); var v01 = Avg(v0, v1); fillQuad(t0, t1, p02, p13, u0, v0, u1, v01); fillQuad(p02, p13, t2, t3, u0, v01, u1, v1); } else if (dH1 || dV1) { // common drawing. if (all_in_front_of_camera(t0, t1, t2, t3)) { blitQuad(t0, t1, t2, t3, u0, v0, u1, v1); } } else { // split in 4. var p01 = Average(t0, t1); var p02 = Average(t0, t2); var p13 = Average(t1, t3); var p23 = Average(t2, t3); var pMid = Average(p02, p13); var u01 = Avg(u0, u1); var v02 = Avg(v0, v1); fillQuad(t0, p01, p02, pMid, u0, v0, u01, v02); fillQuad(p01, t1, pMid, p13, u01, v0, u1, v02); fillQuad(p02, pMid, t2, p23, u0, v02, u01, v1); fillQuad(pMid, p13, p23, t3, u01, v02, u1, v1); } }

Adrian, thank you so much! That's exactly what i wanted to know, it's amazing how clear your code is, it's very easy to understand. So that's the way you were handling perspective correction and all this time you were not using near clipping, very happy to know :) ! Is it a better ideia to use quad for levels then?

@@LeoOno Yeah, that's the technique I'm using in this map, for example: ua-cam.com/video/xqNtphSlWpg/v-deo.html But I don't always apply this kind of dynamic tesselation, just for "level" stuff, or large stuff. Small things like boxes, for instance, if necessary, are subdivided from the beggining. And since my 3D maps are all "boxy" for now (and for the past years) I haven't need to add tesselable triangles to the engine. I've the code for a tesselable triangle, thought. I don't really use it that much. You can see it here in the Quake map: ua-cam.com/video/HGk8WOZUPbQ/v-deo.html It is more or less the same (while writing this, I notice a mistake in the other comment so check it out). void render() { // start recursion sending 3D vertices and UV info. fillTri(t0, t1, t2, uv0, uv1, uv2); } private void fillTri(Vector3D t0, Vector3D t1, Vector3D t2, UVMapping uv0, UVMapping uv1, UVMapping uv2) { if (all_behind_the_camera(t0, t1, t2)) { return; } if (any_behind_the_camera(t0, t1, t2)) { // Split in 4. fillTri4(t0, t1, t2, uv0, uv1, uv2); } else { var p0 = ProjectToScreen(t0); var p1 = ProjectToScreen(t1); var p2 = ProjectToScreen(t2); if (none_on_screen(p0, p1, p2)) { return; } if (Max( GetDistance2D(p0, p1), GetDistance2D(p0, p2), GetDistance2D(p1, p2)) < minSizePolygon) { // Draw without subdividing blitTri(t0, t1, t2, uv0, uv1, uv2); } else { // Split. fillTri4(t0, t1, t2, uv0, uv1, uv2); } } } private void fillTri4(Vector3D t0, Vector3D t1, Vector3D t2, UVMapping uv0, UVMapping uv1, UVMapping uv2) { var dH = GetDistance3D(t0, t1); var dV = GetDistance3D(t0, t2); var dD = GetDistance3D(t1, t2); var dH1 = dH < 1f; var dV1 = dV < 1f; var dD1 = dD < 1f; var dHV2 = dH / dV; if (dH1 && dV1 && dD1) { if (all_in_front_of_camera(t0, t1, t2)) { // draw without subdividing. blitTri(t0, t1, t2, uv0, uv1, uv2); } } else if (dD > dV && dD > dH) { // Split in 2. var t12 = Average(t1, t2); var uv12 = UVMapping.Average(uv1, uv2); fillTri(t0, t12, t2, uv0, uv12, uv2); fillTri(t0, t1, t12, uv0, uv1, uv12); } else if (dHV2 >= 2f) { // Split in 2. var t01 = Average(t0, t1); var uv01 = UVMapping.Average(uv0, uv1); fillTri(t0, t01, t2, uv0, uv01, uv2); fillTri(t01, t1, t2, uv01, uv1, uv2); } else if (dHV2 <= 0.5f) { // Split in 2. var t02 = Average(t0, t2); var uv02 = UVMapping.Average(uv0, uv2); fillTri(t0, t1, t02, uv0, uv1, uv02); fillTri(t02, t1, t2, uv02, uv1, uv2); } else if (dH1 || dV1) { if (all_in_front_of_camera(t0, t1, t2)) { // draw without subdividing. blitTri( t0, t1, t2, uv0, uv1, uv2); } } else { // Split in 4. var t01 = Average(t0, t1); var t02 = Average(t0, t2); var t12 = Average(t1, t2); var uv01 = UVMapping.Average(uv0, uv1); var uv02 = UVMapping.Average(uv0, uv2); var uv12 = UVMapping.Average(uv1, uv2); fillTri(t0, t01, t02, uv0, uv01, uv02); fillTri(t01, t1, t12, uv01, uv1, uv12); fillTri(t02, t12, t2, uv02, uv12, uv2); fillTri(t12, t02, t01, uv12, uv02, uv01); } }

Thanks man! I hope I don't disappoint anyone.

Thanks man! Although there is still a long way to go. I just hope I can materialize all the ideas I have for this project.

🤣😂😂🤣 Sorry about that, but I'd be lying if I said that wasn't the idea!

Gracias!! Sí, sí, tengo un editor que hice (bastante rudimentario) para este tipo de mapas. Fijate en este video, que lo muestro: ua-cam.com/video/wQ-ug6OPn-k/v-deo.html Y la estructura la vas a ver ahí en ese video: es un grafo de triángulos llamadas particiones agrupados en "Sectores" que se conectan mediante portales. O sea, no BSP, sino más parecido a la Build Engine (igualmente todos los enfoques siguen los mismos principios de subdividir el espacio en figuras convexas conectadas), y eventualmente guardo el mapa en un XML. Este es un ejemplo de un mapa chiquito que tenía para hacer pruebas: github.com/adri-kriptok/games/blob/master/Kriptok.Intruder/Scenes/Maps/Map00_Test/Map.wldx

Yeah... There was a problem with the audio. I didn't realize it until I watch it on my phone. I'm gonna have to re record it...

Thanks! And yup! It's all the same engine. I developed skeletal animation long ago, but I don't use it that much because it takes too much work. Since I use ".mqo" files to load models, I cannot store the skeletal information in the file, and I've to create the skeleton and assign dependencies all in code. I made this with no research at all, so it's probably a poor implementation, useful enough only for the projects I make. Don't know if ".obj" allow skeletal information, but I haven't found a simple basic editor for ".obj" files either. So let me know your findings, please. I would love to use this feature more, if I find easier ways to model and to animate!

Hi, man! Thanks! Maybe one day when I get my college degree and have a lot more of free time!

You're right. The hud is very annoying. But it also helps with the performance (there's less screen to render). Anyway this was just for showing the "mode". The game is gonna stay pseudo 3D, and I'll eventually have to find something else to do with isometric voxels.

Thank you. I hope I can fix all the issues and bugs, eventually. Not to mention the lag... Also, I don't know much about network game architecture, so I'll just make it up as I go.

Thanks!!