BDX alpha release: Testers wanted.

Game Engine Game Engine Support and Discussion
41

I don’t really see the utility of alphabetical ordering in a digital, easily searchable medium.

Also, given a short link tree at the top of the page, I don’t think everything needs to be a link, either.

Documentation is really something that should be open to, and crafted by the community. A doc generator doesn’t really allow for that; There’s one format, following a specific annotation model, and that’s it.

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.

As long as the images are served, it doesn’t really matter where they come from (imgur should be pretty reliable).

If you really want to store on github, you can clone the wiki repo, and put images in the “images” directory. Then you just “git add” the new files, commit, and push (that’s how I put up the BDX logo).

@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?

https://github.com/GoranM/bdx/wiki/API#texanim

42

I don’t suppose I disagree with you on the alphabetical ordering part (it is easy to just use the browser’s search), but I think we should at least put API in separate pages. At least then, if you’re using the browser’s search function to find API functions, you can do so easily rather than getting hung up on similarly named pieces (i.e. looking for mesh() methods in the GameObject class, not Mesh() classes or the word “mesh” in other methods or classes). I guess my question is, why have the API in a long single page?

OK, maybe I’ll go with imgur or another repo or something.

Thanks for the documentation on the texture animation component.

43

I think, that the api should be structured so that it would be easy to read and have small examples, but thats from me. Im gonna wait, until theres more.

44

It think it’s elegant - everything being in just one markdown file, which is clear enough to read in its raw form, even in a simple text editor. Also, having everything in one file makes mass search and replace a little easier.

However, your point about search is valid, and I think it justifies a split -> I moved all the classes into their own pages.

@Akira_San

Did you try running BDX on your system?

45

Yes, it run, until i added a text and error shows. Os Win7 64bit

46

Hello! I posted an issue in the same report than MrPutuLips https://github.com/GoranM/bdx/issues/2 at the bottom of the page… I don’t know how to manually install the addon…

EDIT: Sorry, that works. I have not read the readme. For inattentive noobs like me, if you want to test Goran’s BDX project, you first have to install java web browser plugin and java development kit:

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

47

Which version did you try?

Did you update the addon properly?

@youle

You provided good information. I modified the wiki Home pages to link back to the README and I modified the dependencies section to make the JDK requirement explicit (instead of just Java).

Thanks!

48

With the new version, it works…
http://www.pasteall.org/pic/show.php?id=80703

49

Scared me for a second :slight_smile:

50

Hey, I’d like to propose the color() function be moved out of the Text class and into the GameObject class. Why? Because the Text() class extends the GameObject() class already, and the final color of the object is something all game objects should be able to alter, not just Text classes.

The GameObject.color() version would probably loop through all materials of the model instance and set the diffuse color to the specified R, G, B, and Alpha values. The Text.color() function would override this, calling the GameObject’s color() function, but without the alpha value. So basically, it would be super.color(r, g, b, 1). However, if the text object can support transparency (by setting a new BlendingAttribute on the material) then BDX could detect that and add the attribute automatically, though it might be better to allow that on a case-by-case basis.

Why now instead of waiting until later (beta or stable)? Because it doesn’t really make sense to go through and document things that are subject to change in the near future - better to get the API in a stable state, and then document it, than to document the API, change it, and then re-document it. In addition, this isn’t really a new feature - it’s already functionally there, just for only Text objects.

Basically, if we know that per-object coloring is something that could (and I think should) be added, and it’s not difficult to add, maybe it should be added before documentation? Unless maybe I’m missing something. Maybe we could add different color() functions for different portions (colorDiffuse, colorSpecular, colorFinal)? I’m looking at this LibGDX ColorAttribute page, by the way, with the Text class using it like so.

What do you guys think?

EDIT: After doing some testing and reading up on avoiding depth problems with transparent objects (that you can see if you change the alpha value of the diffuse color of a material), it’d probably be best to handle that all later. It doesn’t seem too difficult, though.

In any case, I modded the color() function and moved it from the Text class to the Gameobject class and have it working with no apparent repercussions.

51

I considered that, but I’m not sure if “color” is the right name for a method that basically multiplies diffuse with texture. For Text, it’s fitting, because characters on bitmap font textures are exclusively white, so the color value you set is the color you actually see.

However, for GameObjects in general … I don’t know if it makes sense.

Maybe “multiplyColor(r, g, b, a)” would be more fitting?

52

“multiplyDiffuse(r,g,b,a)”? That way we could have multiple versions? Or maybe “multiplyColor(r,g,b,a, component)”, where component is a constant or string signifying diffuse, specular, or the final color (or others)? I think I like this approach, since it’s easy to expand to other elements when lighting works. I think I prefer a constant approach (multiplyColor(COLOR_DIFFUSE)) vs. string approach (multiplyColor(“diffuse”)), since there’s less of a chance for error and auto-completes.

With multiple functions, you won’t multiply the final color and tint the specular highlights of shaders by accident, for example.

53

I also think it wise to caution against adding multiple means of achieving the same thing. I’m not sure personally whether I think it’s worth adding a function solely devoted to an iteration + multiplication operation.

54

For now, I think “multiplyColor(float r, float g, float b, float a)” would be sufficient.

If there’s really a need to specify different color attribute types in the future, we can always overload with:

“multiplyColor(float r, float g, float b, float a, long caType)”.

55

Generating now…

Any way to add a progress meter? I can’t tell if it’s hung up, or just taking a long time.

56

OK, I’m just about to commit and push, and then make a pull request. I also added a multiplyColor() getter function that just returns the multiply color of the first material. Good or bad?

57

I don’t know. You should be able to see what’s happening in the terminal.

@SolarLune

Sounds good. Just make sure to return the color as a Vector4f (since javax.vecmath is already used throughout the API, it makes more sense to lean on that, then to dip in libgdx packages … right?).

58

I guess so? I don’t know, it depends on convenience (how people might want to directly access returned colors to manipulate them and then re-set them) and the overall planned path for the API (if all of the LibGDX ‘support’ types like “Color” will be replaced by BDX equivalents). Anyway, pull request submitted.

59

OK.

It’s merged in, and the new release is up.

Thanks!

60

Maybe adding the api into tables will make it easy to read.