Join us on Discord!
You can help CodeWalrus stay online by donating here.
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - catastropher

#16
Quote from: gameblabla on July 04, 2017, 12:03:16 AM
I'm currently using Devuan linux (a Debian fork) and i can compile stuff.
Should i compile myself or should i try out your binaries?
Awesome! Truth be told I don't have any binaries, so if you could compile it yourself that'd be great XD It's not quite ready for the first test though, I'll need a few more days to finish the current the sprint. I'll let you know when I'm ready! Thanks! :)
#17
Quote from: 123outerme on July 02, 2017, 07:33:00 PM
So you need beta testers, right? I would love to test! I have a monochrome Nspire, if that is helpful information for you.
Quote from: gameblabla on July 03, 2017, 01:45:54 AM
I have a TI-Nspire CX and i would love to try it !
How fast is it ?
Awesome!!! Thank you guys! At the moment, it's still just PC because it's much easier to develop on (though I will soon produce builds for the calcs as well). Do either of you run Linux by any chance? My goal is to have a new testable release every 1-2 weeks to get things moving along.
#18
Hey guys! I'm back by (un?)popular demand! Very big things have been happing with X3D. First off, X3D has been going through a major rewrite. Why? Because I'm working on loading Quake level files! As much as I liked XBuilder, I was never going to get anywhere with it. This way, we can use the Quake toolchain for creating maps. Also, I'm implementing a number of Quake technologies to speed up level rendering (such as binary space partitioning and potential visibility sets). This is incredibly exciting because the engine is actually making progress. This screenshot may not look like much, but this is actually the first level of Quake loaded into X3D:

[spoiler=First Level of Quake][/spoiler]

The thing is, I really really need beta testers. Also, it would be a huuuuuge motivation if people were trying out the stuff I was writing as I worked on it. If you're interested, please let me know! It would be a huge help!
#19
Quote from: _iPhoenix_ on June 11, 2017, 10:22:30 PM
It sounds great!

I really like it, even though I'm generally not a fan of the style!
Hey thanks, I really appreciate it! :3 I'm trying to branch out and write new stuff!
#20
Hey guys! Finally back after a long and terrible semester! Anyway, I've started to get back into composing again and I'm learning FL studio! Here's a WIP song that I started a few weeks ago. Please let me know what you guys think so far! Any feedback is very much appreciated! :3 Link
#21
Thanks guys! :D I'm going to take development one step at a time. First I'm going to get it to run, then I'll make it run fast and with low amounts of memory. For now though, I have an exciting new feature working: decal textures! In addition to being to put a primary texture on a wall, you can now add decal textures (such as Walrii and the Aperture logo in the screenshot below!)

[spoiler=XBuilder Decal Textures][/spoiler]

I have many more exciting features in the works! Mwhahahah- *cough cough wheeze*
#22
Indeed, each surface will take more RAM. However, I'm taking the approach that Quake did: surface caching. When the level first loads, none of the surfaces are built. When a wall is seen, the surface is built and cached. In subsequent frames, the cached version of the texture is used. If the wall hasn't been seen for a few frames though, the memory is released. As only a portion of the walls are ever visible at any given moment, the memory penalty shouldn't be too high. Quake reserved 500k for surface cache iirc. It's difficult to estimate how much memory will be necessary though... I'll have to experiment once I have a real level to play with :)
#23
I finally got the primary texture tool working! :D It allows you to put textures on the walls and adjust the following parameters:

  • texture coordinate offsets
  • angle
  • scale
This comes as part of a huge upgrade to how X3D does texture mapping. Instead of having separate wall textures, decal textures, lightmaps, etc, everything gets built into one combined "surface" for each wall. I will make a post later on explaining why surfaces are awesome, but for now, here are some screenshots of the primary texture tool:

[spoiler=Primary Texture Tool]
Outside the level:


Top down:


Inside looking up:

[/spoiler]
Next up is working on putting decal textures on wall e.g. an Aperture Science logo :D After that, I'll be writing a new lightmap compiler and updating the surface rendering to do perspective-correction every 16 pixels. I'll post an update when I have more!
#24
Quote from: ztortat on January 01, 2017, 03:17:56 PM
i'm trying to find a download but i cant find it is it just me or there is none?
  ???
Right now there aren't any official builds (you'd have to build it from source, which is available on my github here: https://github.com/catastropher). Currently though, the engine is a bit of a mess because I'm upgrading several components now that I'm getting a real level editor somewhat working (https://codewalr.us/index.php?topic=1802.0). I'd suggest waiting a little while as I get this mess untangled haha
#25
Quote from: DJ Omnimaga on December 31, 2016, 06:22:55 AM
Nice to see an editor and level maker. Will we be able to import textures directly in it by the way? X3D is coming along pretty nicely :3=
Thanks! Indeed, textures can be imported into it directly (though they shouldn't be bigger than 128x128 for speed reasons!) Phase one of texture editing is done: you can now import textures and select a texture from a texture picker I created. Here's a screenshot with a bunch of textures I stole from a quake texture pack:

[spoiler=Texture Picker][/spoiler]

The next phase is actually being able to attach a texture to a wall! This will require modifications to the level format, a new tool for the GUI, and various other changes. I'll post an update when I have it working! :D
#26
So one of the things that's made developing anything for X3D difficult is the lack of tools. So, I've been working on a new level editor called XBuilder! It will provide GUI tools for easily making levels. It'll also handle a number of tasks (such as building light maps) that are currently done by the engine itself. This will greatly reduce the complexity of X3D's source code. Originally, it was just going to be an X3D application, but now I'm integrating in ImGui so it'll have a real GUI. Here are a few screenshots of what I have so far. Anything in red is geometry that already exists, blue means it's selected, and gray means it's a preview of what the resulting geometry would be. Also notice that it supports input in different distance units:

[spoiler=XBuilder]





[/spoiler]

The source is of course on github. I'm going to be adding several more tools in the coming weeks. I'm going to need alpha testers so please let me know if you're interested! For the time being, I'm going to work on the texture tool so you can put a texture on a face :D
#27
I'm gay but I have no idea how to feel about what I just watched lol
#28
Quote from: DJ Omnimaga on December 22, 2016, 08:49:33 AM
Aaah I see. You shouldn't worry about if you are posting too much updates or not on the forums. People generally like updates :). Of course it can take a while before people get time to reply so sometimes you might have to post twice in a row but for project updates it's fine. I'm glad at least that this project is still alive :)
Awesome! I'll be sure to post my progress more often again :)

Quote from: DJ Omnimaga on December 22, 2016, 08:49:33 AM
XBuilder seems interesting. I wonder how easy it will be to use? Because I always had issues understanding how 3D level editors worked. Just with F-Zero X it takes me 3 hours to get a semi decent custom track to work >.<
My goal is to make XBuilder really easy to use. Here's a screenie of me making a quick level:

[spoiler=XBuilder][/spoiler]

As I've mentioned previously, levels in X3D are constructed of convex prisms (called "segments"). You can't see the mouse, but when a face's outline changes color, that means I clicked it. Blue is the primary selected face and white is the secondary - you can add a segment connecting the two selected faces. In this case, I added some octagonal prisms and used the extrude, connect, and shrink face tools to make the level. Oh, fun fact, XBuilder uses X3D for rendering haha

Quote from: DJ Omnimaga on December 22, 2016, 08:49:33 AM
By the way, what are the current compatible platforms?
Currently builds only work for Nspire and PC, but I will add more ports later on. At this point, the engine has diverged so much from its original form that it'd be nearly impossible to get to build for the 68k's anymore.

I just finished implementing X3D's .pak loader, which loads archive files (in the format used by Quake). This means levels can finally have multiple files packed into one nice archive. Now, instead of having to have dozens of files for a level you can just have one :D Now that that is complete, I'm going to implement adding textures to walls in XBuilder. Lamely, until this point, all the textures you've seen have been hard-coded on the walls and you couldn't add more textures.
#29
Hey guys! Sorry for the long hiatus, I had to take a break from the project for about two months for school/work. But, I have a number of exciting things in the works:

  • XBuilder, X3D's level editor is in the works! You can already do basic level editing (I rewrote the entire thing yesterday)
  • You can load models in the .obj file format (I loaded in the Utah Teapot!) but right now you can only render them in wireframe. Solid will come soon
  • Matrices are being upgraded to be 4x4 instead of 3x3. This means you'll be able to make things like joints and robotic arms
  • A better lightmap compiler that uses raytcasting instead of shadow mapping to get more accurate lights
  • Major code refactoring for cleaner code :D
  • A new combined lightmap/texture renderer that does perspective-correct texture mapping every 16 pixels
  • Several other improvements lol

XBuilder is my main focus for the moment because it's hard to test things without a real level. Too bad I suck at level design  :'( Oh, and one of my classmates has expressed interest in joining the project so I may not be totally alone in working on it anymore!

Quote from: DJ Omnimaga on December 21, 2016, 07:22:36 AM
I hope @catastropher still plans to post some updates to the forums in the future. I noticed this project is still being updated regularly, but now he only posts updates on Github :(
Sorry!!! I got really busy with life for a while; also I worry that sometimes I post too much and people get sick of hearing about it haha

Quote from: ztortat on December 20, 2016, 10:39:40 PM
O.O i am dying but sadly i don't have any supported calculators. :(
Hi! X3D runs on PC as well if you still want to try it (though things are in the process of being upgraded so the test project doesn't do too much at the moment)! As always, if anyone want to join the team, I can always use help with X3D, XBuilder, or soon to be XPortal :D At some point, I'll need to find people good at making Portal levels, though that's still a bit of a ways off haha
#30
When I was writing the texture mapper for X3D, I figured out a way to avoid doing the texels[v * tex_w + u] calculation, or any sort of complex logic to update an internal pointer. I just pre-multiply v by the width of the texture and make sure that only multiples of tex_w are counted (since it's interpolated, you could end up with e.g. v = 2.5 * tex_w, which would give you two and a half scanlines which is wrong) with v by doing a bitmask:

// Texture size of 64 -> 6 bits
const int TEX_BITS = 6;

// Fixed point precision for u and v
const int FRAC_BITS = 10;

fp du = ((right->u - left->u) << FRAC_BITS) / dx;
fp u = left->u << FRAC_BITS;

// Premultiply v by the width of the texture (make sure the type of v is big enough!)
fp dv = ((right->v - left->v) << (FRAC_BITS + TEX_BITS)) / dx;
fp v = left->v << (FRAC_BITS + TEX_BITS);

...

// Mask because only whole multiples of tex_w are meaningful (i.e. whole scanlines of texels)
const int v_mask = ((1 << TEX_BITS) - 1) << (FRAC_BITS + TEX_BITS);

for(int i = left->x; i <= right->x; ++i) {
    int index = ((v & v_mask) + u) >> FRAC_BITS;
   
    *screen_ptr = texels[index];
   
    ++screen_ptr;
    u += du;
    v += dv;
    ...
}


Using a more complex mask, this can also be used for super fast texture wrapping. Let me know if you're interested and I can give you more details!
Powered by EzPortal