BDX alpha release: Testers wanted.

There are definitely trade-offs, but for the most part, I think that many problems addressed by generators can be solved with a simple search and replace operation.

And yes, a page per class seems reasonable, for a manual approach.

Also, where are the LibGDX (com.badlogic.*) dependencies? Are they downloaded somewhere?

I assume they are in your gradle cache, and that assumes that you created a project with BDX before you actually try developing BDX :slight_smile:

So, yeah, it’s a hack, but gradle was so ridiculously slow a few months ago, that I didn’t even consider using it for building BDX.

Eventually, it would probably make sense to use gradle for building BDX itself, but for now, good documentation is actually more important, in my view.

Ah, I see. OK, thanks for that - I’ll make sure to put that in the “Using BDX” page if I make it.

Fooling around with getting the LibGDX references resolved in IntelliJ. Not sure how exactly to go about it… Maybe importing the Gradle project will work.

EDIT: OK, I think I might have found a nice, simpler (?) way to go about it… Gonna try it out on a fresh build.

Oh, and on a side-note, would it be a bit easier to drop the Directory Name from the add-on? Maybe it could just make the directory name from the project name, substituting underscores for spaces.

OK, so I’ve been attempting to figure this out, but I’m not making any headway. I’ve got an object called “Player” in the scene I’m using, and a Player.java file in the core/src/java project path directory, next to “BDXApp.java”. No matter what, I’m getting:



C:\Users\SolarLune\My Projects\BDX\Slice\core\src\solarlune\slice\inst\Scene.jav
a:12: error: cannot find symbol
                        return new Player();
                                   ^
  symbol:   class Player
  location: class Scene
1 error
1 warning
:core:compileJava FAILED


FAILURE: Build failed with an exception.



So I’m unsure of exactly what the issue might be. The actual Player.java file is really simple, so I’m not sure where I’m going wrong:



import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.g3d.Material;
import com.badlogic.gdx.graphics.g3d.attributes.BlendingAttribute;
import com.nilunder.bdx.GameObject;
import java.lang.System;

public class Player extends GameObject{
}

Maybe, but someone might want to name the project directory something slightly different from the package name.

Typing out the name of the project directory is not that difficult, and the flexibility might be worth it (for some people).

Although, I don’t really have strong feelings about it one way or the other.

I’ll address your build problem in the issue tracker.

Thanks, it was that I forgot to put the package of the file in the Player.java file.

Welp, I’ve got a few notes and an outline for a basic BDX tutorial on the Wiki.

As a question, do you plan to overload most of the LibGDX types with BDX specific ones, or just leave them? Or maybe focus on the Blender-specific things, like lights, cameras, etc.? I notice that you’re using PerspectiveCam directly in scene.java, for example. Is the goal to have no LibGDX stuff exposed to BDX (through wrapping LibGDX classes with BDX classes)?


On a side-note, a couple of times when I went to test my project, I got an error like:


* What went wrong:
java.net.BindException: Address already in use: Cannot bind

I was thinking this meant that I pressed P to compile while the game wasn’t finished getting cleaned up or something, and so the game didn’t properly close. The game must use a port to pass data, and that port was being used by the finished game, which is why it couldn’t be bound. I went to my Process Explorer and killed the java process, which worked once, but not the other times it happened.

Come to think of it now, IntelliJ (the IDE I’m using) is using JDK in the project as well as Blender invoking Java through BDX. IntelliJ must have been doing some kind of code completion or something with Java, which blocked me from starting it using probably the same port (I’m guessing to redirect console output or something). Anyway, that’s something for me to keep in mind.


Also, hurrah. Got it up and running and have the little dude moving around and stuff. :slight_smile:


Great!

I pushed an example API page. Does the format seem clear enough? I’m kinda thinking that I would want to have everything on a single page, but I’m not really sure.

As a question, do you plan to overload most of the LibGDX types with BDX specific ones

Yes. There are very few LibGDX types that could fit directly/cleanly into the BDX simulation model (which I want to keep as simple as possible).

Also, I don’t want LibGDX API changes to propagate directly into the BDX API.

IntelliJ must have been doing some kind of code completion or something with Java, which blocked me from starting it using probably the same port (I’m guessing to redirect console output or something).

I don’t know if it’s code completion, but it wouldn’t surprise me if IntelliJ hijacked the existing gradle daemon, originally started by BDX.

Not work on blender 2.72b Linux, 64 bits.

Report Error
Failed to get addons path

Logo I made for this project if you want to use it:


.blend attached

Attachments

bdxlogo.blend (688 KB)

^ There already is a logo on the Wiki.

Whoops, didn’t mean to double-post.

Ah, I saw the example API page. Seems pretty easy to understand, but I don’t think having a single page for everything is a good idea. It seems like it would complicate things. Having one page per class would probably be recommended. As a side-note, it should be fairly easy to set up an ability to download the API when it’s finished.

Making new BDX types for each concept and class in LibGDX (light, joystick, etc) seems logical.

I asked before, but just to confirm: Should we could have a list of planned features or goals to implement / add? I think it would be useful, especially for new developers who are looking for simple new features to add or work on, or just looking to see the progress to get BDX types in equivalence to LibGDX.


I tried a simple HTML build earlier today using “gradlew html:superDev”, and after downloading additional files, the build failed with:



Compiling module solarlune.slice.GdxDefinitionSuperdev
   [ERROR] Errors in 'file:/C:/Users/SolarLune/My%20Projects/BDX/Slice/core/src/
solarlune/slice/BdxApp.java'
      [ERROR] Line 26: No source code is available for type com.nilunder.bdx.Bdx; did you forget to inherit a required module?
      [ERROR] Line 29: No source code is available for type com.nilunder.bdx.Scene; did you forget to inherit a required module?
      [ERROR] Line 29: No source code is available for type com.nilunder.bdx.Instantiator; did you forget to inherit a required module?
      [ERROR] Line 55: No source code is available for type com.nilunder.bdx.GameObject; did you forget to inherit a required module?


before other errors. So maybe HTML5 will require a bit of massaging to get to work correctly.

Super!

Just wondering, are you planning to add methods to the GameObject such as:

  • velocityLocal() -> velocity() is global, right? Since there’s also rotate() and rotateLocal().
  • rayCast()
  • color()
  • mesh() - with maybe submodules: Mesh.replace(); Mesh.transform(); Mesh.uvTransform()

And another question (hope it’s not to much): will GLSL be supported, sometime in the future?

I’m for everything on one page. Searching with the browsers search bar can access everything. It would be nice to have a small index with hyperlinks of the modules and containing classes on top of the page.

^ Raycasting (for collisions) seems to be supported through the Scene object (which you can get access to via the game object’s scene field). The function’s just called “ray()”, and returns a RayHit object.

That… Looks a lot better. Didn’t know the wiki was existent, just thought those articles were there. Cool beans :slight_smile:

Super! This is even better. Should be a method of the Scene anyway. Thanks for reminding me that I can actually look at the source code.

^ No problem. Until the API is up, that’s the best docs we can get, haha.

Wrote a new couple of parts to the basic tutorial. Also a resources page with links to some programs that you can use to make resources for your game.

I’d like to add images to tutorials to assist visually, but there’s no such functionality exposed on a base level for Github contributors; would you mind if I opened an issue to put images in, Goran? Kind of a hack, I know, but supposedly it works. :stuck_out_tongue:

Thanks, SolarLune, for taking the effort and contribute to the project.

In what way?

Making new BDX types for each concept and class in LibGDX (light, joystick, etc) seems logical.

For the LibGDX types that actually make sense in the BDX simulation model, yes. We should also try our best to make a better API, instead of just simple wraps (in many cases, we’ll actually have to do that, because many LibGDX types don’t fit directly/elegantly into the existing BDX architecture.

It’s important that we discuss the benefits and drawbacks of each API addition, before we just start pushing-in whatever comes to mind.

Quality over quantity is a good mantra to follow.

Should we could have a list of planned features or goals to implement / add?

Until we reach a stable beta, I don’t think we should add any new features, and so, I don’t think a “roadmap” makes sense at this point; It’s important to get the stuff that’s already there working properly, and well documented, before we potentially make more work for ourselves.

If you want to make a Joystick input (or maybe “Gamepad” would be more relevant naming?) you can definitely do that, but just don’t make that PR (Pull Request) until 0.1.0 (beta).

I tried a simple HTML build earlier today using “gradlew html:superDev”, and after downloading additional files, the build failed

Ok, when you can, make an issue.

I’d like to add images to tutorials to assist visually, but there’s no such functionality exposed on a base level for Github contributors; would you mind if I opened an issue to put images in, Goran?

Markdown syntax doesn’t work? I mean:

![image.png](http://ulr.to/image.png)

I’m pretty sure that should work for any github account.

Either way, I don’t think this is an issue I could close, because it’s about github features, not BDX … Maybe I misunderstood what you meant.

Yeah, that’s exactly what I was thinking.

And another question (hope it’s not to much): will GLSL be supported, sometime in the future?

The existing LibGDX pipeline supports custom shaders, but their Material concepts (the methods by which they feed data to shaders) may not align all that well with a “compositor-like” approach that I have in mind.

It should be possible to work something out, but I don’t plan to focus on that until we’re well on our way to 1.0.0.

Added another tutorial talking about the project structure (as far as I understand it, haha).

@Raco - NP, man.

I dunno, I just think having separated pages for each API concept is easier to deal with, and makes things easier to search for (though I know Ctrl+F exists)? I guess the difference is minimal, and it could always be separated if necessary.

EDIT: After going to edit the API, maybe we should go with an automated process after all. That way it’d be alphabetically sorted (so we don’t have to manually put reactionForce() below end(), for example). I think it would also auto-link to the API pages, right? So everywhere that says “GameObject” points to GameObject’s API page?

Yeah, that makes sense.

Yeah, “Gamepad” would be better naming, probably. And yeah, I think getting what’s there working and documented would probably be a good idea firstly.

I meant that we can upload images to issues for Github to host. That way we could use Github’s issue system to host images for the Wiki, rather than having to host them on external sites.


That doesn’t sound right - is that all the command prompt says?

@Goran - I’ve been looking around, but I’m not certain how the TexAnim component works. What “sequence” do I have to provide it? A file?