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

Topics - catastropher

#1
Other / I Graduated!
May 12, 2018, 03:34:29 PM
Well, I finally complete my masters today! I'm looking forward to getting back into the community and having time to work on projects again! :D
#2
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
#3
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
#4
X3D has been in development for over a year now. At times, progress has been very fast, and other times, it's gone painfully slow. I've learned many hard lessons on how to become a good developer over the course of writing it. However, I have tended to rush things and, overall, have made a terrible mess of the project. While I am not totally starting over, I am creating a development plan on how to move forward because, right now, the code is too terrible to continue. It's time to do things right so that the project actually makes some progress.

The new version of X3D will following the following development strategy:

       
  • Development will be broken into phases, or iterations. That way, we have a goal that we're moving towards.
  • At the end of each phase will be a small, working game that the community can play around with.
  • Feedback will be welcome at anytime and bugs will no longer hang around for months :) It would be awesome if some programmers would be willing to mess around with the library and create some things so I can get feedback!
  • A phase must be stable before moving onto the next one.
  • No hacky solutions will be implemented to rush things, as this just creates technical debt that must be dealt with later. Also, code must be kept clean at all times!
  • The entire development process will be transparent so people know what's being developed. Also, people can join the project anytime if they want to contribute.
If you're curious as to what the current development plan looks like, take a look here.
At anytime, to see what's currently in development, please see the Trello board here.

Please let me know if you have any feedback or suggestions!
#5
Hey, here are some songs songs I'm working on! The first one is called "Desert Side-Scroller) and, as the name suggests, is meant to kind of have an 80's video game side-scroller feel. I still have a lot of work to do on it, but lemme know what you think so far! :D Here's the link (hosted on my google drive because I don't have a soundcloud yet :P): https://goo.gl/kMGDVN

The second one is called "Starblazer" and was inspired by me playing this game called "Xonotic" a while back. Here's the link: https://goo.gl/uhO6o9 This one also needs a lot of work and I'm not entirely sure where to go with it from here. I haven't played the game in a while, so maybe I need to play it again to get more inspiration? :P

Thanks for any comments and feedback!
#6
Hi guys, I'm trying to get TiLP to work on Windows 7 64-bit, but I keep getting a popup that says "The procedure entry point g_assertion_message_expr could not be located in the dynamic link library libglib-2.0-0.dll. I've tried uninstalling/reinstalling, installing different version of TiLP, removing all other versions of GTK+, and installing Glade (as suggested in a post that it may be a path issue and Glade would resolve it). Does anyone have any idea what could be causing this? Thanks!
#7
Hi guys, to be totally honest X3D is my first ever C library (or library for that matter :P ). I'm just trying to figure out what a good naming convention will be for various things. For structures, I currently have all of my structures prefixed with "X3D_", followed by the name in Pascal Case e.g.
X3D_RenderContext.
First off, does this seem like a reasonable way to name structures? Second, I have several structures that represent the same idea, but with different types of member variables (my best analogy is a C++ template).  For example, I have 3D vectors, some that need to hold int16's, int32's, or uint8's. My current convention is that I put the "subtype" after the structure name:


typedef struct {
  int16 x, y, z;
} X3D_Vex3D_int16;

typedef struct {
  int32 x, y, z;
} X3D_Vex3D_int32;


The problem is, I'm using int16 vectors all over the place and barely using the others, and it gets annoying to type out such a long name. Would it be confusing to have "X3D_Vex3D" be a shorthand for "X3D_Vex3D_int16", and if you need anything else then use the long name? That is,

typedef X3D_Vex3D_int16 X3D_Vex3D;


My next question is about function naming. Since C lacks classes and namespaces, I'm trying to figure out how to group related functions that operate on a common object together (almost like a class). For example, suppose I have functions that e.g. create a new 2D polygon, draw a 2D polygon, and find the geometric center of one. At first, I though I should name the methods in this format:

x3d_[struct type being operated on]_[name]


For example:

x3d_polygon2d_create()
x3d_polygon2d_draw()
x3d_polygon2d_center()


That way, it would be clear that all of these methods "operate" on an X3D_Polygon2D. As you can see, though, these names start to get long faaast. Suppose I want to have a function that normalizes an int32 vector. This becomes:

x3d_vex3d_int32_normalize()


I mean it's really clear what this is doing from the name, but will people be willing to type out something so long? Also, is the ordering ok? It could just as easily be

x3d_normalize_vex3d_int32()
x3d_create_polygon2d()
x3d_init_rendercontext()


So, I guess my main questions are:

       
  • Should all of my structures/functions begin with the "X3D" prefix, or is this just unnecessarily increasing the number of keystrokes?
  • Is my solution to "template" types reasonable? Can I have a "default" type like Vex3D_int16 for the most common case?
  • Should I follow a strict, consistent naming convention for functions based on the type they're operating on?
  • Which order seems better, "x3d_create_polygon2d" or "x3d_polygon2d_create"?
I should point out that 1) as many of these functions as possible are declared inline or static inline, and 2) I'm using Doxygen to generate documentation. I really appreciate any help you guys can give me because I'm driving myself crazy trying to figure out what convention to use. Thanks!
#8
Earlier this year I posted on Omnimaga about X3D, my 3D engine for the 68k calcs. After a month hiatus for health reasons, I resumed work on it in May :D Some of you may recall the dazzling light bridge from earlier this year:



Currently, I am in the process of rewriting the engine to support more complex geometry. It's been a long and slow process (I'm currently interning full time as a software engineer), but I've started to make some progress. The last version had levels which were constructed of interconnected cubes. The player could walk around inside the resulting structure, which proved to be very efficient. However, my whole goal of starting X3D was to get Descent to run on the 68k calcs, and many rooms in Descent are constructed of 20 or more cubes, which is just too much to handle. So, this new version will allow levels to be constructed of prisms instead of just cubes. What do I mean by prisms? Here's an example of an octagonal prism:



The idea is you have two bases, each with the same number of points. However, the bases can be stretched, skewed, and rotated, so long as the resultant 3D shape is convex. My ultimate goal for Descent 68k is to merge the cubes in complex rooms into large convex prisms. This is several times more efficient to render than the same room partitioned into cubes.

So far, I have created a new clipping algorithm that clips prisms against a 2D polygon. A fast algorithm for this is crucial for a portal renderer like X3D. So far so good!



Anyway, this time around, it's going to have a lot of cool features. I'm hoping to get some people involved on the project or at least make some games with it once complete (it will be a TIGCC/GCC4TI C library). Let me know if you're interested!
Powered by EzPortal