Tmesh versus Tentity
BlitzMax Forums/MiniB3D Module/Tmesh versus Tentity
| ||
| The troubles I am having trying to manipulate entities are draining my damn patience. Tmesh commands work without problems, but Tmeshes are not practical for memory conservation reasons. Can somebody please take a look at what's causing the confusion with Tentities please? Alpha, and Brushes are useless with multiple Tentities in a type, but are very important!!! It's got to be something simple.. Like why the red component is ignored if painting an entity with a brush? I don't know C whatever and don't know where to look to fix these bugs. |
| ||
| Can you give an example of the bugs? I have no problems with tmeshes or tentitys... |
| ||
| Check this thread thread here Entityalpha() bug?? http://www.blitzbasic.com/Community/posts.php?topic=90238 Or the brush bug here: http://www.blitzbasic.com/Community/posts.php?topic=90243 As mentioned - Tmeshes are unnaffected. |
| ||
It could help to update your video card driver. I did have trouble using EntityAlpha and EntityColor as well, due to my graphical card being buggy, but I was able to work around it using:glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL,GL_SINGLE_COLOR)'GL_SEPARATE_SPECULAR_COLOR)<--original value set by minib3d After using Graphics3D. Also after using EndMax2D, btw, as it resets this setting. |
| ||
| Hey thanks - I'll try this now. |
| ||
| No - no change...Still only works if I don't apply '1.0' alpha value to a solid tile in my entity list - has to be 0.9999 or something...Bloody baffled! |
| ||
| An enitiy alpha value of 1.0 causes it to be rendered in standard order, and possibly some other affects, as opposed to < 1 where it is manually draw ordered. Don't know why this would affect you, but it seems something there is getting broken... Can you confirm you have the most up to date minib3d and blitzmax? Does this happen in a simple sample program you could share? I'm quite confused on it ignoring red values in EntityColor... Specifically looking through your snipet in the alpha bug post, I can see ways it could be a pointer issue and not actually a minib3d problem, but without seeing more it's impossible to tell... |
| ||
| Bmax is 1.39 and miniB3D is the latest version on the Wiki page. Tell me please what you think about the possibilty of it being a pointer problem? The original code used 'mesh' as part of my type field, but I changed it to 'ent' just in case something was going wrong with the mesh\entity pointer. |
| ||
| In you snippet you're referencing m_picked and I don't know where that comes from, I assume it's a global entity you use to hold results from a pick call... and is tile_list a TList? and it's a list of tile_set types apparently, but those are your own type, and I assume tile_set.mesh is the actual mesh/entity you want to be referencing but I don't know... While it is odd that it doesn't work right when using TEntity's, and does with with TMesh's, is there a particular reason you're using TEntity's rather than TMesh's? Even if you refer to a mesh as an entity, all the fields of a mesh are still there, you can typecast it into a mesh, so there's no memory savings... May not fix the problem at the core, but it may get you going... |
| ||
| From what I understand in Blitz3D - copymesh() makes a whole new individual base mesh using more ram, whilst copyentity() references just the one original loaded mesh. I see that using copymesh() uses more ram in my debug screen info. It's what I don't understand - I already saw that Tmesh extends Tentity, so I figure something fundamental is different in the way they are being handled under the miniB3D bonnet but I don't have a clue where to look. I've not tried typecasting a Tentity into a Tmesh so maybe I'll give it a try and see. Thanks. |
| ||
| You should maybe best open up the files in blitzmax\mod\sidesign.mod\minib3d.mod\ and add debug code (print or debuglog) to trace where it goes wrong. I would look into CopyEntity. That is, I believe, TMesh.bmx->CopyEntity. A TMesh is a form of a TEntity, and a TEntity by itself doesn't render at all. TMesh overrides the Update method, which is responsible for rendering the mesh. So that method also would be a good place to investigate. Another thing to track is the RenderWorld command. It ends up in the TCamera->Update method. There, everything is set up and rendered. Although the actual mesh rendering is done by TMesh->Update itself. It is difficult if others can't reproduce the error. Another thought: maybe you could assign the same 'brush' to each TEntity: local cube:TMesh = createcube() local cube2:TMesh = copyentity(cube) cube2.brush = cube.brushI didn't test this, as I have an self-adapted version of minib3d. |
| ||
| Hmmm - just tried that. Used the same brush on all of them - no difference. Literally the last tile in the list is the only 'picked' tile that get's its alpha adjusted to 0.5..then every other tile disappears completely when they are supposed to be set 1.0...all other commands such as scale,entityFX etc. work normally and affect the correct tiles, so I know it's not my flakey code :) I suppose I'll have to dig deeper. |
   |