Request: Extra camera functions
Blitz3D Forums/Blitz3D Programming/Request: Extra camera functions
| ||
| Please could we have functions to retreive info from a camera such as zoom and viewport information? They would make life so much easier. |
| ||
| Well... since you do have to set up those for yourself, you should know them... :) Default CameraZoom is 1, and default CameraViewport is full screen... http://www.blitzbasic.co.nz/b3ddocs/command.php?name=CameraZoom&ref=3d_cat http://www.blitzbasic.co.nz/b3ddocs/command.php?name=CameraViewport&ref=3d_cat ...Or am I missing something here? |
| ||
| Well... since you do have to set up those for yourself, you should know them... :) Default CameraZoom is 1, and default CameraViewport is full screen... That's like saying well you set the position of the entity yourself, so you should know it, so why do you need EntityX(), EntityY() and EntityZ()? This cropped up because I was writing a function which works on several cameras, but each time I call the function I have to remember all the settings for each camera and pass them to the function - because the function makes changes to the camera viewport and then needs to change it back as I am rendering to textures. The point is, why should I have to track information that is already being tracked by Blitz? It would be so much easier if you could just call GetCameraZoom, CameraViewportWidth and CameraViewportHeight. There are other areas where the reverse commands for setting are missing, such as ScaleEntity for example. I know there are ways round the lack of these commands, but really these commands should exist. Edit: Just found the post on EntityScaleX etc, but it still stands that there is no function to return the camera viewport or zoom settings. |
| ||
| Could you not just use variables and use the function(s) on the variables not the actual camera settings. Then, whenever you need to know the zoom or viewport for whichever camera, you can work with the variable? |
| ||
| Could you not just use variables and use the function(s) on the variables not the actual camera settings. Then, whenever you need to know the zoom or viewport for whichever camera, you can work with the variable? Yes I know that, I understand how to get round it and that is exactly what I am doing (that is what I meant when I said 'remember all the settings'). The point I'm making is that if those commands were available I would only have to pass the camera to the function. |
| ||
| Now you're just being lazy ^^ How about making a camera type to contain all your camera variables AND the camera entity.. no problemo ^^ |
| ||
| Now you're just being lazy Why does it always come down to this? WTF does it mean to be a lazy programmer? I mean, I could call you lazy for not programming in 100% asm. What is wrong with wanting to be able to both read and write settings from entities? In fact it is the mark of a well designed language and I am afraid that it is one of Blitz weaknesses. By passing only the camera there is less to go wrong, no need to update the camera and keep the variables in sync, less chance of bugs, less time debugging and if that makes me a lazy programmer then by God I am proud to be a lazy programmer. |
| ||
| I agree completely. |
| ||
| A call to get information is just slower than making an array Dim Cameras.CamType(x) so it's normally a far better idea to save information than request it realtime |
| ||
| A call to get information is just slower than making an array But I'd rather have the choice than have the choice made for me by the lack of a command. Besides, the overhead difference between function call and reading a variable is becoming practically negligable. The problem I'm finding with Blitz are there often are too many 'work around' solutions for things that, in my opinion, should be in the language. |
| ||
| I completly agree with you. If wanting this is being lazy, then we're all lazy anyway by using blitz. I mean we could very well write our own engines... Seriously, having to do things that blitz already does but do not expose is just the result of an obvious lack in blitz. Plus everytime you have to do such workarounds to write your libs, you put an additional and unneeded dependancy that make it harder to integerate with other libs. A call to get information is just slower than making an array That's a pretty poor argument actually, because blitz has the ability to inline every call to built-in commands. Don(t ask me if it does, but it *could* easily, in which case it would be even faster than using an array, *and* transparent. And quite frnakly, I couldn't care less from any "overhead" here. These kind of infinitesimal overheads can only have an impact if you call the function thousands of times, like in an intensive inner loop. In which case you can simply call the funciton once before the loop and store it in a variable, and access that variable in the loop.Dim Cameras.CamType(x) so it's normally a far better idea to save information than request it realtime So in fact what *is* a far better idea is to drop this habit of seeking optimizations in places where it hasn't the slightest impact on speed. Better think higher level, and do local optimization only where and when needed. Just my 2 cents. |
| ||
| I agree with the need for these functions. Lets say you want to write a generic library that does stuff with the camera, or use a htird party library. Then these functions become essential, because you don't know what variable, if any, the main program stores the value in. When writing a generic library, it's best if it is as muich of a "black box" as possible, operating without outside uesr input. It's very annoying to have to force the user to call say, "GUI_SetCameraViewPort" in addition to the Blitz function to set the camera's viewport size every time they want to set the viewport size. That is a poor example though, because it oversimplifies the problem. Even if you call a special setcameraviewport for a single camera, what if you have two? What if you also change their fog color, fog range, and their near and far range? Now you've got a problem cause you're either going to have to pass that information every time you update the system for the specific camera you're rendering to at that time, or you're going to be forced into a one camera system, or worse, you might be forced to call special funcions to "add" and "free" cameras in the GUI system when you make a new camera so that it can loop through them all and find the one referenced by the user so it can access its data... And then you'll still be stuck calling functions to update this data when you make a change to anything. I'm not being unrealistic here either... I've run into this problem on numberous occasions when writing my systems. Most annoying is the lack of a set of functions to dtermine entity scale on each axis, though thankfully it is possible to calculate that manually by accessing the transformation matrices. Still, it sucks having to have an entityscaleX, EntityscaleY, and entityscalez function in every lib with a different name. It would be nice if they were built in with the ideal name instead. And requiring the user to include one or more additional libraries with just those functions in it is not acceptable because that makes using the stuff more confusing. |
| ||
| Basically any value that you can set should have a retrieve function. It makes life so much easier... |
| ||
| I agree. |
| ||
| I also agree we need this. Infact, this topic has come up on more that one occassion and I STILL dont understand why these functions have been ommitted. :/ |
| ||
| I can't see the point. There are hundreds of these types of emmisions in Blitz, which Mark has evidently realised. Of course if you add all these missing functions you suddenly have a command list twice as long and very ugly. Plus who can be bothered coding all those simple functions anyway? Not him, I'll reckon. Much easier to just give us direct access to Blitz's internal types for objects... And since that seems to be the way BMax is going (here we go), may as well just concentrate on that and let B3D die. =] |
| ||
| Of course if you add all these missing functions you suddenly have a command list twice as long and very ugly. What kind of argument is that? Let's not have too many commands because it makes the list ugly? Plus who can be bothered coding all those simple functions anyway? Yes, let's have blitz with only cool functions that do spiffy things. Let's not bother with the basics because they're too boring to program. And since that seems to be the way BMax is going (here we go), may as well just concentrate on that and let B3D die. =] Yes, let's all do nothing until BMax arrives... Frankly, Hotcakes, there is plenty of life left in Blitz and I sincerely hope that Mark could be bothered to spend as much time on simple, but essential, functions as he does on the more interesting ones. |
| ||
| What kind of argument is that? Let's not have too many commands because it makes the list ugly? Yeh. What's wrong with that? ;] Yes, let's have blitz with only cool functions that do spiffy things. Let's not bother with the basics because they're too boring to program. Is there a problem? =] Yes, let's all do nothing until BMax arrives... No no, I'm a firm believer in the 'use what you got not what you anticipate' speech. Frankly, Hotcakes, there is plenty of life left in Blitz and I sincerely hope that Mark could be bothered to spend as much time on simple, but essential, functions as he does on the more interesting ones. It's funny then, that in all the years since BlitzBasic was released, some of these simplest types of functions and requests for them have been completely ignored! Ha ha. Or something. |
| ||
| Yeh. What's wrong with that? ;] Because it is just the most plain stupid argument for not having a command. I'm sure BlitzMax when it becomes available (shortly after the release of Duke Nukem Forever) it will have more commands than Blitz, which obviously won't make you happy. Is there a problem? =] Yes, because if any language doesn't get the basics right and only concentrates on the bells and whistles will just be a complete piece of crap. |
| ||
| I still think its kind of lazy.. Is so easy to implement the solution, but instead you go on this forum and request that Blitz should do it for you. Personally I wouldn't bother requesting this, but thats just me.. I agree that there's many things still missing from Blitz.. Double precision floats for example.. this is a thing you can't work around "easily". (some people might suggest going the UserLib route just to prove me wrong and such) CameraZoom() functions are something you can write yourself. |
| ||
| Personally I wouldn't bother requesting this, but thats just me.. Isn't it ironic then that you spend the time bothering to argue against the function? What does it matter to you if Blitz has this function or not? Nothing. Will it take too much time for Mark to write the function? No, it just has to return a value. And just because it is 'easy' doesn't necessarily mean it is good code - in fact I consider it unnecessary to have to separately track data that is already tracked by Blitz internally and run the possible risk of your variable going out of sync and spend ages trawling through code to find out where you made a mistake. Every function to set a value should have a function to read the value back. |
| ||
| I don't care if it gets included or not. I still believe what I first said though. |
| ||
| I personally think such functions would be useful. |
| ||
| . |
| ||
| i think the arguement from the experienced sswift shows why we need these functions and should get them, also like mentioned, every function that sets a value should have a function to get that value too. |
| ||
| I think Ken takes smiley-riddled comments too seriously. |
| ||
| Hotcakes, if you have nothing constructive to say then go and play somewhere else, like in front of a speeding truck ;-) |
| ||
| I have to admit, of all the things Blitz3d might need, this isn't exactly one I'd be too worried about compared to others. It's not as if the workaround is complicated or difficult. Yeah, it would be nice to have the commands in there, but I'm of the attitude that the language does what it does, and we have to fill in the blanks. If that means buying a DLL plugin, then it's a pain, but there you go. If it just means making a type and making sure to keep an eye on it's values, I can live with that. |
| ||
| Glenny: Personally, I think the chance to add simple functions to further the development of an application instead of, basically, forcing the user to write his or her own functions, variables, etc. to monitor information which should normally be readily available is bad. In any case, I've already stated my view on this so I won't be making any more replies unless neccessary. My apologies for doing more than saying 'yes' or 'no'. (I don't mean that as an insult or sarcasm, by the way) |
| ||
| The real question is; Do you want Mark to take time away from upgrading Blitz3D, BlitzPlus, Maplet, and writing BlitzMax for trivial functions. I'm not saying that it shouldn't be added. I agree with the argument that for every SET, there should be a GET. I just would rather see Mark spend his valuable time on non-trivial things. |
| ||
| I don't mean you WolRon, just replying to half of the rest of the thread: Since you're "not lazy" at all, why don't you go and work with C++ or something? |
| ||
| I can't help wondering if this type of function and many others couldn't be remadied by Mark giving us the handles to Blitz commands and telling us the offsets were these things are stored in the command. Kind of like the old C64 days when we had access to the ROM Kernal so we could read it directly. If Mark wrote just one new command which will give us access to the Blitz kernal and told us were the important offsets are, all these problems would be solved. You just call that function, with the offset and it returns whatever value you need. Or something along this line. I don't know how blitz does things internally, but I do think that one general command could do something like this. An example of what I am saying for the camera is: If we could get a handle to were a camera is stored in memory, and at what offset the zoom factor is by using a peek or poke command, we could read or write the zoom factor. The command to do this could be a function like "GetEntityHandle" Then we just need to know the structure of how each type of entity is stored in blitz, to get any offset value. This kind of function would not be very difficult to write for someone with Mark's talent. But while on the subject: Something I would really like to see added to blitz, is inline assembly ability. That has access to the frontbuffer, backbuffer, imagebuffer, or a memory bank. That would make blitz3D's capabilities truely endless. Hopefully using MASM32 coding style. Then if we need a new command, just write it. Asm code could be shared with other users, and Blitz would begin to Evolve on its own. AWSOME THOUGHT! This is something all powerfull languages have. And if not ever implimented in Blitz3D I hope it will be included in the next Blitz language. |
   |