Blitz Hardwired - DX9 and DX11 Userlib (Part VIII)
Community Forums/Showcase/Blitz Hardwired - DX9 and DX11 Userlib (Part VIII)
| ||
| Hello all, last thread was getting long - so here we go again with a new one.... A new release out tonight. I will not say much about it because I'm dead tired and off to bed after this. Suffice it to say that I may have solved the HW shader woes. The only way to be sure is that you test it. Instancing should now work with a little luck (test10.bb for example). The dwarves in the dx9 version of maze.bb are rendered using the HW shaders, the line 'dxEntityHWShaders dw(d),True' in the bb code takes care of this. They should now render with textures, or at least I hope so. @MadJack, I haven't quite cracked dxPointEntity but I am working on it. Sorry....        |
| ||
| Suffice it to say that I may have solved the HW shader woes [...] Instancing should now work with a little luck (test10.bb for example). Woo hoo!  I also have textured dwarves in DX9 and 11 for maze.bb, both with and without hardware shaders. |
| ||
| ^~~~ Now THAT is AWESOME! How did you texture your dwarves, @BlitzSupport? :) Thanks! Sincerely, ~GF |
| ||
| OK, good news and a little bad news: maze.bb - Good: In DX9 all perfect now! - Bad : In DX11 it's back to the floors and different parts of dwarfs flickering in turn. Which is a bit strange cos I think in one of the previous versions I you had already nailed it. But I might be wrong of course as I don't know what's going on underneath the hood. Unfortunately I can't retrace for you which version it was cos there's no mention of a version number along the download buttons at different stages of the threads.(dunno if would have helped?) test10.bb & test10d.bb : Great! I can see(for the first time!) the dwarfs are really going for it! Looks the same as in screenshots above. Great job, this is nearing completion I guess. |
| ||
| Maze DirectX 11 mode: FPS Average: 646 on an Nvidia GeForce GTX 750 Ti Graphics Card :) |
| ||
| How did you texture your dwarves, @BlitzSupport? :) @Guy Fawkes: Um, I ran test10.bb! I'm on the same graphics card, BTW, GeForce GTX 750 Ti -- just realised I hadn't updated my sig since I have them turned off. Now corrected... |
| ||
| Well I'll be d**ned! :D This is REALLY a VERY popular Graphics Card! :D |
| ||
| EDIT: Nvm, I replaced the DECLs file and it's fine now. :) Sorry for the non-needed post. |
| ||
| Ok, what am I doing wrong here? Why is this saying "Array is out of bounds" ? Which variable did I make the array's current value go past the array's max value? (This is hardwired related). Thanks to all that help! =) Sincerely, ~GF |
| ||
| Set your max_instance_elements to a constant. Global arrays do not like variables for thier size. Does 25*25=1000? If not, there's your answer. You could always follow the program's flow in bb debug mode. In any case, it doesn't seem hardwired related - more a bug in your coding I would say.* @Rick, you see - it wasn't your gfx card that was at fault at all. It was my sloppy programming ;D |
| ||
| Got sick of the above not working, so I redid it & it now works! Here's the code for everyone if you're like me & like nice, "spaghettified" code wrapped up in a nice, neat function or 2! test10d.bb: Also works in BlitzPlus! Thanks again for the help, Ploppy! :) Sincerely, ~GF |
| ||
| Nice one GF. (see: I knew there was still good in him) Good to see more and more people are contributing some code/experimenting with HW. |
| ||
| Thanks alot, @Rick Nasher! :) |
| ||
| Just a little note about the code and how hardwired works. Since you are using the instancing technique and the dx9 standard ffp does not support instancing, hardwired will recognise that the HW shaders need to be used and will automatically flip to this rendering mode. This means that the command 'dxHWShaders True' is not really needed. It's not doing any harm, of course, but it isn't changing a thing. 'dxHWShaders True' will tell hardwired to use it's internal shaders to render for any following mesh rendered, even if dx9 supports it. Sometimes it is useful to use this, sometimes not. Nice conversion BTW, much tidier than my stuff... |
| ||
| Thanks, @Ploppy! =) |
| ||
| EDIT: New Thread for this project |
| ||
| Interesting fx. |
| ||
| GF, please don't fill up this thread with lots of updates of this, just the final copy if you like. Let's keep this mainly hardwired please. Else, start a new thread if you like. It's good what you are doing, but it is an adaptation, it belongs here as much as it doesn't. Otherwize, this thread is going to become very long in a very short time, and most of it signed GuyFawkes. Nothing wrong with with that in some respects but that is not what the majority came here for. I don't want to sound grumpy. Thanx |
| ||
| Ok, sorry Ploppy :3 |
| ||
| No probs, I must say I am a little blown away of how devoted you are to hardwired already. I guess I can't deny your fidelity in this project - I hope it all comes to a complete form sometime so your time invested into it becomes worthwhile. Thanks for the faith :D |
| ||
| No problem. Without Hardwired, I wouldn't be able to finish my program. You are a GOD among men, Ploppy! :) You truely are! Other than you {its' creator}, I am the most devoted of all the people on this entire forum! Of course, you have most likely already deduced this. And no, I should be thanking YOU for the faith! :) Hardwired is GOD! :D So thank YOU, Ploppy! Sincerely, ~GF |
| ||
| I really really hope I do not let you down. Believe me, I am just as prone to errors and to mishaps as any man. So I all I am saying is if Hardwired does not end up in a complete in any form for any reason (anything is possible) although this far from being my wish, that you will not take it too badly. If you or anyone gets too involved with HW, although I appreciate the attention very much, and for some reason or other it falls flat on it's face you may head for a fall also. HW is still very much in developement and anything can happen. I am just simply amazed of how I've got so far - especially since I hardly knew a thing about c++ or dx last year. I guess I am saying I would rather avoid disappointing anyone. So keep an open mind about this one for your sake. I am no god, a god is sure about his creation - I am not. My wife will also confirm freely that I am far from being a god ;D For me, my personal programming gods have to be Mark Sibly, David Braben and of course Peter Molyneux. I am very very far from being in thier league - these guys have this talent in the thier veins and for me are completely incomparable. |
| ||
| Ploppy: In the chance that this DOES fail, if you release the source on Github under a license, I'm SURE somebody will pick it up and help you out. I myself wouldn't release the source unless I was 100% SURE I was going to fail. I understand that. But if you keep the source to yourself after you are 100% SURE that you are going to fail at it, that's making the BEST thing to EVER happen to ALL of Blitz stop in its' tracks. I want to see Hardwired become a milestone. So you see, Ploppy. You WON'T fail us. :) Sincerely, ~GF |
| ||
(old obsolete post).  |
| ||
| Hey Ploppy, can you add a "dxcopyinstancer(instance%, parent%=0)" command so that we can make multiple copies of instances? Or if not, is there a simple work around that you can show me that would do the same thing? Thanks again, kind sir! :) Sincerely, ~GF |
| ||
| Hi gf, I will do but maybe not quite yet - stuff 2 do. But I will say this - you can hook an instancer onto multiple entities, if you wish these entities to share the same qualities. |
| ||
| Strange: when things work for some machines, they tend to not work for others and vice versa. What could be causing this? I thought the whole point of DX was that people wouldn't be able to hit hardware directly so things would be standardized and work the same on all machines cable of running according to the specifications. |
| ||
| Dx isn't the problem here, it's probably my sloppy programming.... Anyway, that said, here is a new little update... 2 New functions... dxInstancerElementActivate(instancer%,element%,activate%) Now you can show or hide an instancer's element if you so desire. Set activate to 0 to hide it, 1 to show the element, and 2 to toggle the current activation status of the element. The activation status defaults to active when a new element is added to an instancer. (test10.bb has been updated to demonstrate...) dxInstancerElementActivated%(instancer%,element%) Returns false if element selected is currently hidden or true is element is active. With the addition of this new technique I'm probably not far from continuing my emitter code - this is where the fun will really start... particle systems (yay :D ). @VirtLands - are you sure you have the latest version? I recognise some bugs you listed that for me that have already been solved. dxCreatePlane.bb will not work, I had put that in as a joke a while ago just for GuyFawkes's benfit - it did display a toy plane on the screen but I have taken it out since :D But I will get round to making the real command. Honestly!!       Thanx again Derron for buttons... |
| ||
| @Ploppy: Can you show me how to attach multiple entities? I tried that last night and it didn't work. I did something like this: Thanks again! :) Sincerely, ~GF |
| ||
| GF, instancers only work with mesh entities. A pivot is basically just a set of coordinates, nothing more. Once you hook an instancer to a mesh, when the renderer comes to rendering the mesh it will take the 'hook' into account and render the mesh x number of times depending on the instancer it is 'hooked' to, changing each new instance's position/color/etc each time depending on how you programmed the instancer in question. In essence, an instancer is just a list of changes to be made to a mesh that is sent to a shader. |
| ||
| Ok, so what do I do in order to like press "C" and make a copy of an instancer? Do I have to create an invisible sphere in order for this to work or what? Thanks! Sincerely, ~GF |
| ||
| Huh???? No speeekee englishaaa... sorreee Be clear, please. I can only eventually help if I know what the heck you're talking about... |
| ||
| I'm trying to use the instancer as a "copy machine". Basically, I'm trying to use the demo I made of test10d.bb & use it to make multiple copies of the instances at will. If you need me to explain more in-depth, I will. Thanks Ploppy! :) Sincerely, ~GF |
| ||
| If you wish, I guess you can use Blitz to make a copy of an instancer. I plan to make a function in hw myself at one point or another, but in Blitz it seems pretty straightforward to do. I can't see what goal you're aiming at exactly but if that's what you want it would I guess it'd go something like the following... I have typed this code right into this post, so I haven't tested it, but it should work. If it doesn't you should get the gist of what I'm getting at - I hope.... |
| ||
| Thanks Ploppy! :D Btw, dxPositionElement() dxRotateElement() and dxScaleElement() should be: dxInstancerPositionElement() dxInstancerRotateElement() dxInstancerScaleElement() Just a heads up! :) Thanks again, Ploppy! :) Sincerely, ~GF |
| ||
| Yup, you're right. Like I said, I typed it quickly from memory and didn't test it... |
| ||
| @Ploppy: Those 2 new commands you added are crashing my test project.. And I believe they're also somehow hiding my instance because my instance was seen fine last night before the upgrade. The function that is crashing it is: dxInstancerElementActivated() Can you please tell me why my dwarves aren't showing up even though I didn't hide them and why the above line crashes my program even though somehow it returns a "1" ? Here's the code (only the hardwired includes folder is needed). Thanks again, Ploppy! =) Sincerely, ~GF |
| ||
| A few extra commands tonight, one more instancer related and two shader effects. dxFreeInstancerElement(instancer%,element%) - Use this to free up and element from a shader. If you free an element that is not the last of the instancer's element count, all following elements will naturally be 1 less. For example, if you free up element n°5 from a 10 element instancer elements 6-10 will become elements 5-9, and the new element count will be 9. dxEntityGreyscale(entity%,enable%) - Quick shader function - set to true to render the entity in greyscale dxEntitySepia(entity%,enable%) - Set to true to render the entity in sepia tone colour These two last commands are valid for any entity, not just instancers. Note that instancers can use this effect but the effect will be performed on the totality of the instances. |
| ||
| <3 Hardwired just keeps getting better and better. But Ploppy, did my last post make sense? :) Thanks again Ploppy! =) Sincerely, ~GF |
| ||
| @GF, Okay solved - download again should be fine now... BTW - dxInstancerElementActivated will not return true if hidden, it returns false if hidden. By default an element's status is set the 'true' |
| ||
| YAY! No crash! :D Thanks Ploppy! :D |
| ||
| New function again... I may get rid of it or program it differently as compiling the shader slows down the execution of a compiled bb for some reason... anyway, for the moment here it is dxEntitySimpleBlur(entity%,enable%) Will set an entity to have a simple horizontal blur shader effect applied to it (see new version of test10.bb for example - get close to a dwarf to see the blur), you may or may not find this handy. |
| ||
| At first all seems to be working fine... But I've noticed that when I first ran another maze.bb in DX9 or DX11(not sure if matters yet, but can't test need to go zzz)then the flickering occurs. If I then restart it's gone and all fine, so looks like something doesn't get properly terminated or so, hence the flicker as it does it twice? Perhaps also explain the slowdown when adding the shader stuff, maybe it's occupying memory? Like the buttons better indeed, bit more neat. :-) |
| ||
| test10d shows both dwarves and terrain and the terrain moves as the camera moves/rotates - so all good as far as I can tell. Maze_horror: both DX9 and DX11 appear to display identically now - although they both show random 'flickering' in the render. |
| ||
| Guys I'm working on a modified version of test10d that when done, I wish for Ploppy to possibly add to the next upcoming releases from now on in the zip file if that's ok with him :) Thanks alot! Sincerely, ~GF |
| ||
| @MadJack - the flickering in maze_horror.bb is intentional - it's in the bb code. I wanted to give it that 'Silent Hill' kind of feeling. 'Silent Hill' was a classic for it's time on the ps1, it gave me the heebie jeebies. It had great gfx, great graphical fx, and even the film adaptation was pretty damn good too IMO. Sean Bean is cool (I was personally gutted when his character died at the end of GOT season 1) @Rick Perhaps also explain the slowdown when adding the shader stuff, maybe it's occupying memory? No problem, I'll explain. When the dll is first initialised, one of it's first jobs to do when initialising directx is to compile the hardwired shaders (both vertex and pixel shaders). The hardwired shaders, written by myself (incrusted into the dll file) are written in HLSL, which is a script file (ascii). DirectX has functions to compile these scripts into assembly that the graphics adapter understands. This directx compile function takes time. Just like for any compiler, the more complex and large the original source, the more time it takes to compile. Once the shaders are compiled, they are kept in memory in order to be used by the pc at a later stage. I am currenly in the progress of writing internal functions that will automatically recompile my HLSL code any time that I modify it and then save the compiled code. This compiled code will then be part of the dll, instead of my script. Once I have finished this improvement, compiling the HW shaders will be essentially skipped over, so you will witness a great improvement in initialization time. I don't know how it goes on your machine, it depends on the processor, but on mine I really am having an important lag in starting a HW compiled bb now, and I don't like that lag. This is thanks to the on-board dx HLSL compiler. So hold on, boot-up improvements are on thier way.... Best regards. @all - You will not hear much from me for the next few days- stuff to do at home and at work... |
| ||
| Have fun @ work, @Ploppy! :) |
| ||
| Ploppy, I just tried the original test10d example from the newest release, and for some reason the dwarves are not showing after being loaded at all. o.o |
| ||
| All the dwarves?? |
| ||
| Yes. every last 1 of them. I used this code from your newest release: |
| ||
| Freaky! |
| ||
| You see it too then, eh? What's the problem? >< |
| ||
| Guy Fawkes you say you are making a DLL for PureBasic with this.Any chance i can have a dabble with it. |
| ||
| Yea, lol. It should be above somewhere. If you can get it working, then by all means go for it! :) |
| ||
| This invisible mesh thing is driving me CRAZY! >< The terrain shows up because it's not a mesh, but the meshes don't! O_O; CRAZY stuff man! O_O; |
| ||
| This invisible mesh thing is driving me CRAZY! >< The terrain shows up because it's not a mesh, but the meshes don't! O_O; CRAZY stuff man! O_O; |
| ||
| Nope cannot find it bud.I looked for it.:) |
| ||
| Sorry buddy. It was in the 7th thread for hardwired. Here's the link: http://www.blitzbasic.com/Community/post.php?topic=102736&post=1232106 Sorry for the inconvenience! Let me know when you get it working. I got it running, just not working >< |
| ||
| You see it too then, eh? Nope, not at all. For me, all is fine.. |
| ||
| New worklog, as from now on news and updates will appear in the worklog.. Later... |
| ||
| Hi Ploppy. I have a feeling it may be my laptop's graphics card because it works fine on my desktop. |
| ||
| It's always laptops isn't it... |
| ||
| Right? -.- |
| ||
| @ GF: Hmm, sofar tested on my lappie only. I'll try on my desktop too, but it's ancient, so it be interesting to see how it will cope. lol. @ Ploppy(and the rest): I've now retried executing the maze.bb example multiple times in both DX9 and DX11 mode and found that if I run in: 1) DX9 mode first, then terminate the program and run in DX11 mode, it will give the 'flickering' textures. At closer inspection, it looks like the walls become without textures and transparent for just a split second, revealing the dwarfs behind it. But same applies to the dwarfs themselves when in front of them, just less clear, they flicker nevertheless in same way; each body part in sequence after the other. 2) DX11 multiple times in a row: all remains OK, no flicker. (~63 FPS) 3) DX9 multiple times in a row: no issues there too. (~37 FPS) -So appears to happen *ONLY* when DX9 has been run first and then the DX11 version. Can anybody confirm this is the same on their machines? 4) Also found (but this is minor)the camera in DX11 is less stable. Seems to have a wobble when moving the mouse to look left/right, which does not occur in DX9 mode. test10.bb and test10d still working fine for me though, the black dwarfs are something I've seen in the very early stages of development, then they disappeared completely until fixed in latest releases. Hope this helps debugging.. |
| ||
| @Rick, do you notice an improvement with the newest version?- it should start up much quicker. This new startup technique is presently only valid for dx9. In the dx11 the other technique is still used - I haven't yet finished the new code for dx11. |
| ||
| @Ploppy: Well, appears to be quick enough, but to be honest: I haven't noticed the lag that much in the sense that it would disturb and keep me from using HW. But now you've said it, there indeed is a HUGE difference between the DX9 and DX11 startup. Don't know how much it was before but currently DX9 takes about 1.5 sec to start while DX11 7.5 sec. Nice job. |
| ||
| Anyone had any problems on "ancient" graphics cards that are on board? o.o |
| ||
| Attention - naturally the gfx cards have to be at least dx9 compatible. I am no miracle worker. |
| ||
| It IS DX9. that's the problem. Infact, it's DX11 >< |
| ||
| Ok cool - just thought I'd clarify. After all, you did say "ancient" not me. |
| ||
| Indeed I did. :) But it's a few years old. Which is why I said ancient. ^_^ |
| ||
| NICE, Ploppy! :D EXTREME increase in speed! :D |
| ||
| Ploppy: I have confirmed it. Your new DLL broke dxCameraPick() somehow. o.o; >< How do I know? Because when I downgraded to 3 days ago's DLL & DECLs files, it magically started picking my objects again. |
| ||
| @Ploppy, Hmm, there may still be a bug (or difference if you like) with the camera: I was going back to work on my 3d planetary thingy and decided to check out the bit of code I used to check the accuracy/workings of the Blitz <> HW commands to see if the wobble is also noticeable there. I found that there is a difference in the camera, the scaling or postitioning of the entities, when compared to Blitz3D's DX7 engine. Just run Planetary Test DX7.bb and Planetary Test DX9.bb and you'll notice the difference.. (please first change the last bit of the dxGraphics3D command in source, cos it has one parameter less since it was created: dxGraphics3D 1024,768,32,1;,1 ) It appears that planet Earth has changed size, distance or orbit when it went from DX7 to DX9..? Oh, and I forgot to mention speed difference, but that's not a bad thing of course ;-) |
| ||
 |
| ||
| Thanks guys for your help and feedback. I'll get back to you all in a few days. Stuff to do... @Vitlands - terrains have nothing to do with projective textures. I am positive the bug comes from my code. I will find that bug...may take me a bit of time but I'll find it... |
| ||
| New worklog entry Ploppy |
| ||
| @Ploppy: I tried your copy instancer code btw. It didn't make a single copy for some reason even though I feel it should have. |
| ||
| That's because you indented the text. It doesn't work when indented. |
| ||
| Ploppy, that wasn't it at all. Indentation or not, I just tested, it still didn't work. |
| ||
| I know that. I was just being silly. Did you really test out if indentation makes a difference? |
| ||
| ROFL! He** no! I was just being a smart***. |
| ||
| So what exactly IS wrong with it? |
| ||
| I do not know. |
| ||
| ... Why won't it function at all? I don't understand. :( :$ |
| ||
| Me neither. |
| ||
| Then how did you think that function could possibly work? |
| ||
| Perhaps it does work perhaps it doesn't, quite frankly I do not know, and I do not want to think about it - that's all. Today I'm not really thinking about hardwired. Other stuff to do, that's why pretty much anything HW/Blitz related is a bit above my head for the moment. |
| ||
| You are a patient man Ploppy. |
| ||
| Haha, yes :D |
| ||
| You have no idea :) |
| ||
After 8 chapters, coder's block is setting in, .....   |
| ||
| Not really. I have lots of small writer's blocks. But if I block somewhere I can always go onto another module in HW and come back to where I blocked later on. So I've always got something on the boil somewhere. It's just that a copy instancer routine is far from beong my personal priority at the moment so I'm not thinking about it at all. Besides my time on the pc is kind of limited at the moment - family responsabilities and all that, not to mention my work. So I cannot pander to all GuyFawkes's relentless requests all the time or I will never advance with my own priorities. I have to make the most of the little time I have in the way I feel advances HW in general and not just for one. Anyway, little update on the worklog... |
| ||
| No problem for the camerapick() bug find, Ploppy. If I find anything else, you will be the first to know :) |
| ||
| Honestly though, I think CopyInstancer() would be a GREAT function to be added within the next few weeks. It only makes sense because copyentity() doesn't work on instancers. |
| ||
| So I cannot pander to all GuyFawkes's relentless requests all the time |
| ||
| Go hijack another thread. -.- I am DONE talking to the likes of you. |
| ||
| Sorry Ploppy, but he's ALWAYS been on my case and I'm getting tired of it. |
| ||
| I guess it must depend on how you look at things. From my perspective it seems that LineOf7s is helping you out. |
| ||
| @Ploppy You still use "gif" for the buttons ... gif only has 1 transparency color - that is why the rounded corners look pixelated. please just use photoshops "web export", select PNG and use more than 256 colors, so the whole transparency gets preserved. PNG should be small enough as we used gradients in the buttons - png likes linear gradients. bye Ron |
| ||
| I downloaded this thinking it was B3D only, i was suprised to find some BMax files. So this can be used as a 3d engine for BMax? If yes, anything i need to know to get started? |
| ||
| Hi, can anyone help ferret with an educated answer? I personally do not use BM and know much about it's workings. But I believe hardwired is completely compatible. To be confirmed by a Bmax user... |
| ||
| There is an example included and it seems to run fine :) |
| ||
| @Ferret -- you should re-run the 'bmxer' program for each new release, as you won't see new commands or fixes otherwise (eg. where parameters have changed), and may cause crashes if anything has changed. I've uploaded an executable version here in case you don't use Blitz3D -- just place it in the main HW folder and run it to produce a new 'hardwiredlib.bmx' for each update. |
| ||
| ^ Nice, @Blitzsupport! :D |
| ||
@Ploppy, I'm not sure if this is another bug or not, but for some reason the following functions: dxEntityX#(ent, glbl%) dxEntityY#(ent, glbl%) dxEntityZ#(ent, glbl%) dxPositionEntity(ent, x#, y#, z#, glbl%) dxRotateEntity(ent, xrot#, yrot#, zrot#, glbl%) dxScaleEntity(ent, xscl#, yscl#, zscl#, glbl%) don't quite get the right results as they do when using regular Blitz3D. The math in my copymesh() code works fine in Blitz3D - DX7, but when I used Hardwired with the same EXACT math and same EXACT "globals" for the parameter, "glbl%", for some reason the math was off and the objects were positioned / rotated / (possibly scaled) wrong. I tried it with both "glbl%" = 0, & "glbl%" = 1, and the math was still off. It was worse infact, when glbl% = 1 for some reason. Hope this can get resolved soon as I look forward to continue using Hardwired! :) Thanks again, Ploppy! Sincerely, ~GF |
| ||
| @Derron - I already told you I did use png for my previous buttons, not gif. I may modify these new ones to png, I may not. Quite honestly a few aesthetically imperfect pixels are not my priority - don't think it'll affect my sales figures :) |
| ||
| Of course it does not change sales figures ... I just told you that you did not export them correctly. I can convert a jpeg to an png but the lost information of the previous export of raw data to jpeg is lost in the png too. So if you export with less transparency values, the png wont bring them back. So when exporting, check double times if you export them with 24 bit, not 256 colors. I do not tell you this because I am pedantic but to make you aware of this because you might do this "wrong" in other areas too (eg. sprites for your games). Another thing (at least I saw it in BlitzMax): if you use PNG optimizers they sometimes break the transparency in BlitzMax - other image viewers display them correctly. So only optimize "full opaque"-images (background assets). bye Ron |
| ||
| @BlitzSupport, Thx, i was wondering what 'bmxer' was for. I ported a project from Minib3d as a test and got it to run in a couple of hours. About png, i don't understand why you would use anything else other then png for game and web graphics. I mi opinion it is the best format for this and i never use anything else in mi programs. Just mi toughts! |
| ||
| @RickNasher Hmm, there may still be a bug (or difference if you like) with the camera: I was going back to work on my 3d planetary thingy and decided to check out the bit of code I used to check the accuracy/workings of the Blitz <> HW commands to see if the wobble is also noticeable there. I found that there is a difference in the camera, the scaling or postitioning of the entities, when compared to Blitz3D's DX7 engine. Just run Planetary Test DX7.bb and Planetary Test DX9.bb and you'll notice the difference.. (please first change the last bit of the dxGraphics3D command in source, cos it has one parameter less since it was created: dxGraphics3D 1024,768,32,1;,1 ) It appears that planet Earth has changed size, distance or orbit when it went from DX7 to DX9..? Oh, and I forgot to mention speed difference, but that's not a bad thing of course ;-) Fixed!! . Thanks as always for the bug report - you were totally right. Should work fine now.... I am currently working on a whole plethora of new functions/commands related to my particle system. With a little luck the first version will be at a releasable state at the end of the weekend. Finger's crossed, but it should be pretty powerful. Bug free?? Well, that's another matter entirely ;D |
| ||
| @GuyFawkes I tested dxEntityX/Y/Z and it seems to work as it should for me.. Example B3D Example Hardwired Both programs give the same results... Could you please explain (if you have a little time with simple code example would help) where your problem lies so I can test it and see what you mean. Thanx |
| ||
| @All I have to say I have pretty much ignored any BlitzMax compatibility with hardwired up until now. I am very happy it seems to be very compatible, but it's just that I don't know much about Bmax so my support is very minimal. I don't think I am capable of much on the Bmax front, but totally understand that Bmax is a highly used and highly powerful medium that many people use. I don't think though my ignorance will much improve, I have tried the BMax demo in the past and didn't get on with it - I don't know why but there we go - horses for courses I guess. What I'm trying to say basically is that if anyone at any stage would like to contribute at any time to relavant Bmax code like BlitzSupport has already done in order to improve the Bmax coverage including docs and demos - I would very much appreciate the help. I will not include anything myself, as I do not have BMax, but it'd be great to have some good support going for that too. I will however, for my part, take Bmax support more seriously and make more of an effort to publicise hardwired as Bmax compatible as much as for B3D and B+.... |
| ||
| I don't think you really need to worry about it -- it should work the same regardless of what language it's called from -- C/C++ included. |
| ||
| @Ploppy: Indeed scaling has been fixed, thank you very much. Only thing I can still see now is the cam wobble in maze.bb DX11 when going left/right using the mouse, which is not there in the DX9 version. Really getting there, better and better all the time. |
| ||
 Very Nice Work!! |
| ||
| Yue, can you please either remove or make that image much smaller? It's taking up alot of wasted space. Thank You! =) |
| ||
| @Yue, good to see you back my friend. |
| ||
| go Ploppy go! |
| ||
| YEA! GO PLOPPY! =D |
| ||
| DxPointEntity still in the fix queue? |
| ||
| @Little Dave: I know of no other way to contact you, but did you receive the last message I posted in this thread to you about Purebasic - Hardwired? Thanks! :) Sincerely, ~GF |
| ||
| DxPointEntity still in the fix queue? Hi, I have been working on it but for some reason or other I have overlooked a vital bit of maths so I still haven't yet cracked it - but I will... |
| ||
| In your own time P. |
| ||
| @MadJack - Cracked dxPointEntity problem. Sorry it took a bit of time, I've been messing with the HW maths for a few days when I've had a spare moment, and at the end the solution was staring me in the face. In any case,here it is. dxPointEntity_test.bb has been included, demostrates that the function does indeed work this time... |
| ||
| Yup, appears to be working alright. Squashed the bug. |
| ||
(old obsolete post).  |
| ||
| dxPointEntity works for me now, along with dxLoadTerrain What's your lappy specs again Virtlands? |
| ||
| @VirtLands - I have just updated the dll, dxLoadTerrain should now work corectly. The image you saw with the dxPointEntity demo is what you are meant to see (the 60fps however comes from fraps and is not blitz/hw related), but for the test_hwshaders.bb you should see many cubes on the screen... @all - I have made some changes to the internal shader handling routines, there may be some speed/compatibility improvements on the dx11 side of things. |
| ||
| @Ploppy: Can you add CopyInstancer() in your own time? :) Tyvm! Sincerely, ~GF |
| ||
| Ok, done. I have tested, and it should work fine.... |
| ||
| Ploppy... I would hug you if I saw you in real life... :D THANK YOU! =D |
| ||
| Ploppy, even though Blitz3D has just gone open source, I STILL hope & PRAY that you continue Hardwired! I'm not a fan of C++... At ALL.. I cannot live without Hardwired. I'm a Blitz3D - Hardwired addict! O_O; |
| ||
| I'm not a fan of c++ either, but sometimes you have just got to get your hands dirty... Well, well, well - B3D has gone open source. Thanks for the info GF, I wasn't aware. For me though this changes nothing about hardwire's future. I still intend to continue with it. It don't know why I would stop - in fact now I can even use Mark Sibly's code as a guide for certain functions so it should help me along. This is very gooooood news for hardwired indeed, though I am surprised that Mark decided to release that too. As for other people jumping on 'the bandwagon' and releasing thier own engines or impovements on b3d. Why not?? Bring them on, the more the merrier. I have nothing to lose, why should I feel threatened in any way??? If I was releasing hardwired for a price, then yes, I could see this as a potential sales risk but this is not the case. The more choice blitz users have out there, the better. It'll be up to them which engine suits them best. And, each engine has it's own qualities. However, to my knowledge, HW is the only one (for the moment) that has dx11 capabilities. No, hardwired is still going strong, even so like I have already said if I do ever give up I too will release on open source. You won't hear too much from me in August though: holiday time... |
| ||
| @Ploppy. that's the spirit and the proper attitude:o) - Have a great holliday, and remember to relax. |
| ||
| CHEERS TO PLOPPY! LONG LIVE BLITZ3D & HARDWIRED! |
| ||
| Ploppy, that glitch I told you about earlier. The one where the 3D isn't showing.. Is there ANY way you can fix that? I think your DLL might have a problem with AMD Radeon graphics cards because I upgraded my drivers last night, and it still didn't show the 3D at all when using hardwired. If it doesn't, then there's something keeping 3D entities hidden because I can see 3D terrains JUST fine. EDIT: MIGHT be a coordinates position issue. Working on it. |
| ||
| Just had a few tests done. The problem is DEFINITELY with your CreateInstancer() code. I just ran the default demos as well as my demo and the only time the dwarf DIDN'T show up is when I tried to create an instance. Hardwired doesn't like AMD Radeon graphics cards for some reason... :( |
| ||
| Does the problem you are having that you described in your penultimate post relate your the problem you are facing as described in your last post or are these two different problems? In any case, can you give me a simple code example that I can test out here to see what result I get? I need to know roughly under what circumstances this happens on your system so I know more or less what to target in my source code. Details count when you can, does instancing work with my example included in test10.bb?? |
| ||
| Yes, it's the same problem. Unfortunately, not on my laptop. On my desktop, it's fine last time I checked, but that may be because my desktop has an NVidia GeForce GTX 750 Ti compared to my laptop which has an AMD Radeon HD 7640G... Here's my laptop specs: As for an example, just open test10.bb with an AMD Radeon graphics card... |
| ||
| And nothing shows?? |
| ||
| Yup. Nothing shows until I comment out the instancer commands. :( |
| ||
| Yup, just did a test on my desktop pc, and it works fine. Hardwired's CreateInstancer() function DEFINITELY has a problem with an AMD Radeon graphics cards... :( |
| ||
| @Ploppy: Maybe Mark decided to 'give' you Blitz3d so you could pick up where he left off and create the thing most Blitz3d fans want to see: the next version. Would be nice if it would help you to build Hardwired even better. However I once heard people commenting about sources he released and they apparently found it rather hard to wrap their head around, but perhaps you have better insights/skill levels. I've seen an interesting suggestion in another thread which I actually think is a good one: someone should incorporate the GUI routines of Blitz+ right into Blitz3d. Which I think they should have done all along to create a language for all purposes. |
| ||
| What Rick said! :D Also, for some reason, when I do: It doesn't copy the new instance automatically where the old one was. It instead ends my program o.O; |
| ||
| @Ploppy: "Well, well, well - B3D has gone open source. Thanks for the info GF, I wasn't aware." That is awesome. Both Blitz3D & BlitzPlus are now open source. ---> http://www.blitzbasic.com/ |
| ||
| @VirtLands: Hehehe Blitz3d x64 suddenly becomes possible indeed yes. But I don't have the dwarves and cubes show up like this. I have em neatly textured. |
| ||
| Yes, the dwarves and cubes are meant to be textured. Did you change the code or is another of hardwired's famous glitches? I do like the colours, in any case... @GuyFawkes, as for your code above, your dxCopyInstancer call does not take the copy's handle into account. Your call will be fruitless using it this way. Just like for copyentity and copymesh, a handle will be returned. |
| ||
| Actually, it does. That's just part of the code. instance is a variable that uses CreateInstancer() I also Global'd instance. |
| ||
| I'm sorry but I have to disagree - in the example you have put into your post you have used dxCopyInstancer like a command and not a function. dxCopyInstancer returns a handle to a newly created instance to where the original data is copied. Without saving this new handle to a variable the command will be useless. |
| ||
| So how exactly would I use the function in above code instead of the way I'm doing it now? I thought it worked like "CopyEntity". |
| ||
| But it does work like copyentity... copy=CopyEntity(original) copy=dxCopyInstancer(original) Both make a copy of the original and return the handle of the copy. Your code was dxCopyInstancer(instance) No wonder you're not getting much from it without saving the copy's handle. And of course, don't forget to hook the copied instancer to an entity if you wish to have any visible change. The same reasoning applies to CopyEntity. If you wish to do anything with it you have keep the handle in a variable. And don't forget that an instancer is NOT in any way a visible object. An instancer is, to all intents and purposes a list of changes that can be made to ANY mesh it is hooked onto. This system means that you can use the same instancer, if you so desire on several entities at the same time. |
| ||
| Then what is the usefulness of dxcopyinstancer() if the instancer can't copy visible objects? x_x And no, THIS is the code I was using: Thanks again, Ploppy! =) Sincerely, ~GF |
| ||
| For me there never was much use, and I even told you that. Remember, it was you that wanted dxCopyInstancer, so I put it in for you. For me I personally don't see much point in copying an instancer for an instancer can be used many times in a render - just hook it on to the entities you wish to inherit the instancer's qualities. An instancer can be hooked onto as many entities as you like. You can also unhook an instancer from a hooked entity at any time. |
| ||
| Yea, true. BUT. I wanted this command because I thought it would make copying of dwarves setup in a matrix-like shape such as a rectangle, much easier to manage. |
| ||
| It's VERY useful. It has the power to manipulate ALL those objects at ONCE! Which I think is a BEAST in itself! :D |
| ||
| I'd LOVE to see a function that can do that in one line. it would be GREAT to be able to copy "matrices" all at once! In your own time, of course. |
| ||
| Do what in one line? You'll have to be more specific as I really do not know what you mean. There are matrices in quite a few objects... |
| ||
| The ability to copy ALL those 400 dwarves in their same positions / rotations / scales / animations that they are currently being drawn at. Basically, some way to create a matrix like this, and the ability to copy it just like a pivot. |
| ||
| So that way, the dwarves can then be manipulated all at the same time. |
| ||
| For Test10.bb and Test_HwShaders.BB, it's a mystery to me why the textures don't show up. The ploppy-code™ remains unchanged.  @G.F.: I tried your sample code, and I only see text as such... |
| ||
| @Virtlands: It should be in the same folder as Ploppy's most recent DLL file :) WITH the hardwired textures / models folder as well :) |
| ||
| What is "it" ? |
| ||
| My Instance source code file should be in the same folder as the extracted Hardwired plugin folder. |
| ||
| Yes it is. |
| ||
| huh.. that's strange. well does the folder have all the terrains / texture folders and stuff? if it doesn't, then that's the problem. if not, then it MAY or MAY NOT be your graphics driver. in which case, i would make sure i have the latest graphics card drivers. if THAT'S not it, then it's your graphics card or your computer itself. in which case, i would make sure everything's up to date and you don't have a virus of any sort. |
| ||
@G.F.>  if THAT'S not it, then it's your graphics card |
| ||
| Well that's strange. You seem to have all the correct files & directories. I would try and update my graphics drivers. |
| ||
| It must be my shader init routines that are not entirely foolproof. I'll work on it - HW is in developement after all... |
| ||
| Maybe try to rename the "Ploppy's DirectX code" if that happened all the times you used this directory name... . Maybe something stumbled over your apostrophe " ' ". bye Ron |
| ||
| The ability to copy ALL those 400 dwarves in their same positions / rotations / scales / animations that they are currently being drawn at. Basically, some way to create a matrix like this, and the ability to copy it just like a pivot. @GuyFawkes - I may be wrong but I really get the feeling you are confusing instancers with entities. These are not at all the same thing. An instancer does not 'save' an entity's positon/animation and keeps no information whatsoever about any specific object. It really is nothing more than a list of changes that can be made at rendertime to any entity of ones choosing. The only way that an entity is linked to an instancer is by hooking them together. When the renderer is executed with the dxRenderWorld command, it will render all visible objects that are not hidden to the render target. If the objects in question are hooked to an instancer (this 'hook' variable is kept in the entity structure - nothing² to do with an instancer's structure), it will take all element information that the entity makes reference to and will render the said entity according to the rules 'programmed' into the instancer. It really is a simple concept and IMHO it is powerful and at the same time an economic method memory-wise of instancing. If you wish to make modifications to separate elements of an instancer you can with one of the several commands I have included, so it is quite versatile in that way. There are obviously some restrictions to the use of instancing, but that is the nature of the beast. Camera picking and collision detection for one become very tricky to perform. However, you do of course get a very fast rendertime compared to dxCopyEntity or any equivalent. One more quote... And no, THIS is the code I was using: Unquote... Please note that in your code you have inputted the line: dxCopyInstancer(instance) dxCopyInstancer is not a command, just like CopyEntity isn't or CopyMesh. They are functions, because they return a value - which in this case is a handle... copy=dxCopyInstancer(instance) would make more sense, for example as you could then hook it onto an entity so that you could use that instancer in rendering. When an instancer is created or copied, it is hooked onto absolutely nothing of course - hardwired cannot guess such things and it's up to the blitz user to tell HW which entities use which instancers. If you use CopyEntity, for example as a command and do not take it's returned value into account you will get a visual result nonetheless. This is because CopyEntity will make a copy of a physically visible entity; so the copy will be visible too and therefore rendered. However if you do not retrieve the handle of this new copy you can do nothing with it - move/rotate/scale/hide/even freeing it up from memory becomes impossible. But an instancer like I said above is not an entity, so if you copy that and do nothing with the returned handle you will have nothing visible at all from it. Getting anything visible from an instancer comes from hooking it to an entity. Without this vital part of the render process, you will have zero result from instancing. |
| ||
| Ok, Ploppy! I see! Thanks alot bud! I'll post results when I get them! :) |
| ||
| Hey. As long as I can "pick" the entities, I do not care HOW they are "picked". |
| ||
| Is there a dummies guide to unpacking/installing the Hardwired.dll? I thought it was just a case of coping the release folder to somewhere in the Blitz3D folder, then coping hardwired.dll and hardwired.decls files into the Blitz3D/userlibs folder. Alas all I've been getting every time I try to run one of the sample programs is an 'User lib not found' runtime error. Help!, what have I missed? |
| ||
| Hi tektoy, first question is have you updated directx9 on your system? If not, it can stop hardwired from running. It also could be a dependancy problem. Hardwired loads up certain dll's when initialised. I have noticed that on an xp system I have tested my userlib that I get the same error message than you. What version of windows do you have? I did in the past have compatibility with xp systems but have since added dependancies to hardwired. I must rework the compatibility side. I will look into this... |
| ||
| Hi there Ploppy, I'm using Win7 64bit. |
| ||
| Ok, have are you sure that dx is up to date?? Try googling it just to be sure. If your directx9 is not the current release version, hardwired will not function. |
| ||
| Thank you Ploppy, you're a genius, just downloaded and installed the June 2010 Directx installer, and what do you know it all works now. Damn, is Win7 really that old?, pity I can't bring myself to 'upgrade' to Win8. Thanks again, off to run all the demos now... And thanks for all your hardwork on Hardwired! |
| ||
| Glad it works for you - thanks for your interest in hardwired. If you find any bugs please don't hesitate to report them. I'm not saying I'll fix them right away but I'll note it down and get round to it at some point or other. This is a very ambitious project for me so for the moment there will be unexpected bugs... |
| ||
| @Ploppy: You CAN pick objects from an instance in SOME way, right? |
| ||
| Mathematically it is definately possible, yes. There will be a cost to be made in processor time though. The beauty that comes from instancers is that the shaders do all the dirty work in copying a mesh many times as far as rendering the mesh is concerned using a constant streaming technique. But for picking, the maths would have to be done by the processor, not the gfx adapter. |
| ||
| I am currently working on the collision routines. This is one of the things I have deliberately been putting to the side because of it's more than usually complex maths that is involved. Thanks to the release of Mark's b3d source, I can use that as an inspiration for my own routines. I have to convert it over as his class structures do not match my own design, but the maths remains the same. With a bit of luck, I'll get that sorted fairly soon. That Mark Sibly is one truly talented guy - he must be armed with at least a good maths degree or two, at a guess. B3d source for me is quite a godsend, and I think I'll be using quite a few things from it to help where hardwired has not yet been completed. Although most b3d commands have now been covered, the majority of the ones that are left for me to complete are the ones that require research and precision that I have yet to acquire. With the release of b3d on open-source, I have certain shortcuts to this knowledge. I also have the added bonus of eventually being able to convert Mark's compiler code as well (perhaps I will, perhaps not). If I do succeed in fully converting it over, the dll userlib will dissappear to essentially become a sort-of unofficial B3d version dx9/11. It is perhaps a pipe-dream, I do not know, but I do dig the idea.... |
| ||
| Ploppy. Is there ANY way (on your own time of course), that you can add camerapick() to hardwired? If you can do that, then I think I can manage making copies and letting shaders do the dirty work, as you say. |
| ||
| @Ploppy: "a sort-of unofficial B3d version dx9/11" That would of course really be wonderful! and what everyone is hoping for. Plus: perhaps I foresee an even more ambitious(yes, we can..? Uh.. well, I can dream of course: "Blitz3dPlus DX9/11 HardWired x64", giving it the BlitzPlus GUI code bits with the fantastic HardWired new commandset and.. in X64. But I'm thrilled already seeing it got this far so, no silly demands here. ;-) Good to hear Mark's code helps with the collision stuff. |
| ||
| @gf - camera picking already exists in hw. But it will not work on instancers. And b4 you ask, no I am not working on that at the moment. |
| ||
( Close Button bug has been fixed by Ploppy. )   |
| ||
| For stuff like that, use: taskkill /F /IM blitzcc.exe I find that easier to use, but that's just me :) |
| ||
| @gf - camera picking already exists in hw. But it will not work on instancers. And b4 you ask, no I am not working on that at the moment. Hi, Ploppy! :) Isn't it true that collision is also part of "picking" objects as well as instancers (tons of objects) in other words? |
| ||
Tasking tasks indeed!  |
| ||
| Uhm - collision routines are not ready yet -that's why I didn't announce that. I must take that demo out, I put it in for my own test purposes. @gf - in answer to your question, yes and no. |
| ||
| Fixed that window close bug - Thanks for the feedback VirtLands... |
| ||
| Sweet, thanks Virtlands & Ploppy! :) Ploppy, wouldn't it be apparent to make the camerapick work with instancers since it after-all is collision-based? |
| ||
| I would drop the subject if I were you - I have noted a good few posts ago that you would like that in HW. But then I would have let it go at least two posts ago. As always you do not respect the complexity of my code, the maths and structures involved, that it may be more complicated than it seems to you and of course that I have my own priorities. If you really wish me to follow your own personal agenda I would suggest you hire me. If not, do what everyone else does, let me know about a loophole/bug, and let me deal with it in my own time and way. Up to you, of course.. |
| ||
| Ploppy>>I have one thing to suggest (if it has not been suggested before) : Separate the detection of collisions and the update of animations. (=no more Updateworld()) Good luck for the next steps. |
| ||
| I see what you are getting at and I like the idea - should be simple to integrate. One of the many many modules I am thinking of adding to Hardwired will be a simple physics engine. I think this will also use the same kind of updating method too. Thanks RemiD |
| ||
| I have tried to code my own collision system in Blitz3d, some ideas : Each turning moving entity which must detect a collision has a collider (ellipsoid or box or capsule or low tris mesh) Each turning moving entity which must be considered as an obstacle has a collidable (low tris mesh) Each static mesh which must be considered as an obstacle has a collidable (low tris mesh) For each collider and for each collidable, i calculate a "MaxXZRadius" which corresponds to the maximum radius on the XZ axises between the origine of the mesh and the farest vertex on the XZ axises The collider is what will "emit" the collision (the turning moving object) the collidable is what will "receive" the collision (the obstacle) Each frame i delete all colliders and i recreate some colliders only if the associated entity is turning moving. The collider must be recreated before turning moving the associated entity Then i detect the collision between colliders and collidables edit : i have added more details
for each collider
for each collidable associated to an entity other than the current collider
calculate if the distanceXZ between the current collider and the collidable is less than current collider XZRadius + collidable XZRadius + collider movement speed
if yes
consider this collidable
if no
do not consider this collidable
store the orientation and the position of the collider
turn move the collider
for each collidable
if the collidable is considered
calculate if the collider collides/intersects with the collidable
if yes
store the collided collidable pointer/reference
store the collided point x,y,z
store the collided normal nx,ny,nz
reposition reoriente the collider to its previous position orientation (if a response stop is needed)
end the collisions detection for this collider (so this detects only the first detected collision, but it is faster)
This works well with colliders ellipsoids against collidables low tris meshes and with linepick against pickables low tris meshes, but it is too slow with colliders low tris meshes against collidables low tris meshes with meshesintersect. Maybe this can give you some ideas... |
| ||
| Hi, Ploppy! :) Any news on hardwired? |
| ||
| Nothing to release yet. I am working on it of course, though less than usual - kids on holidays from school do not permit much free time ;) I am still working on converting over Mark's code and integrating into Hw, I'm learning quite a lot at the same time. With a little luck collision stuff will be complete this weekend, part of it works already. Would be nice to get that complete then, as after that I'm away from home on holiday... |
| ||
| |
| ||
| Any updates lately? |
| ||
| On holiday... this message sent using my mobile. See you in september. |
| ||
| happy holidays! |
| ||
| Everybody has a summer holiday, no more worries for a.. week or two. So Ploppy's going on a.. summer holiday, to make dream come true.. for me and you. (Courtesy: Cliff Richard, hopefully not a criminal) - Greetings Ploppy, enjoy your holidays, kids, wife etc. - |
| ||
| Happy holidays Ploppy! =) |
| ||
| New thread... |
   |