iMiniB3D V0.5
BlitzMax Forums/MiniB3D Module/iMiniB3D V0.5
| ||
| This version tidies things up a bit. I've rejigged the project for Xcode 4, added retina support (that should work with the iPad 3) and made a few other additions and fixes. Download from here. GitHub: https://github.com/si-design/iminib3d |
| ||
| Fantastic, can't wait to take it for a spin... Wonder if I left any custom tweaks in my current bundle.. I think it was just fixes which you've included... Dear god I hope... |
| ||
| It looks like you've added sphere mapping (as noted re the teapot example) is cube mapping in too? Is it tentative (hence not updating the diff list from minib3d) or stable (just slow as noted...) |
| ||
| Well done Simon, great stuff. have just had a good test, all worked first time. Last edited 2012 |
| ||
| ima747 - no I haven't really added sphere mapping I'm afraid (not possible in hardware with ES 1.1). The teapot example just does it all in code, and is quite slow as a result. |
| ||
| aaah good to know. fingers crossed that es2.0 wiggles it's way into minib3d before I find enough time to take my Sledgehammer of Progress (tm) to it with the inevitable results... |
| ||
| What's the best way to go about submitting code enhancements? Specifically I've tweaked texture2D.h/mm to be thread safe so you can spawn textures from background threads (very handy if you're doing dynamic loading especially on newer hardware where there's multiple cores...) and would like to toss it your way for possible inclusion... Last edited 2012 |
| ||
| There is a bug with Pick::CameraPick() on retina displays. Applying the screen scale as it does now makes it pick in the wrong place. Commenting out the scale adjustments makes it work properly again. I don't use CameraProject but I assume it would suffer the a similar problem. The device has sub-pixels on a retina display but it doesn't expose them. Everything is handled in "screen units", with 1 unit being 1 pixel on a standard resolution display. There's no need to translate between true pixels and screen units because everything works in screen units and the hardware takes care of sub units as needed. I would assume (though I don't know for a fact) that that affects OpenGL as well, in that everything is still handled in screen units. Graphics require a double resolution variant but if you access the double resolution variant directly you get it's true size (which is double the standard version obviously). Apple's directed approach is to put both in your program and let the image loading routines (such as [UIImage imageNamed:@..."]) figure handle the loading and scaling for you. It returns a picture with the dimensions of the standard resolution image but actually the double data of the @2x variant. I think load texture could use a review as well, since it's explicitly stating the image path from a CString I think it may be bypassing the retina versions if available (though I don't know for sure). Less of an issue in 3D, and may be intentional (we have to keep a tight watch on the size of the pictures an all...) but it wouldn't be expected to skip a retina version if available on an appropriate device... |
| ||
| Confirmed the camera project, projecting 0,0,0 on a 3Gs returns 160x240 (center of screen). on a 4S it return 80x120 (proper position divided by scale). Would recommend disabling the camera project scale adjustment as well. (last 2 lines in CameraProject()) |
| ||
| Will have to take a look, but I'm sure I got it working correctly (for example, the examples which use camera pick, zombie and collisions, both work correctly). There is a need to convert between points and pixels, as touch co-ords are in points, but the OpenGL side of things is still in pixels (twice as many with retina). Last edited 2012 |
| ||
| Sorry, forgot to mention, the preferred way to submit changes would be via GitHub. |
| ||
| Hmmm, don't know what to say beyond I get the wrong coords unless I remove the scale factor on retina devices (where scale returns 2 instead of 1). Tested and confirmed on iPhone 3Gs, iPhone 4, iPhone 4S, iPad 1, iPad 2. Results are universal as expected on all devices with scale factoring removed, and returns the wrong position only on retina devices when scale is taken into account. Granted this is just in my project, I haven't made an explicit test but as it relies exclusively on touch input for 3D space interaction it's pretty clear when the values get cut in half :0) I don't recall if it affected retina mode in the simulator, but something tells me it *didn't*... |
| ||
| Submitted a pull request with the Texture2D changes. I think I did it right and assume it will notify you, but new to github so just following up here... |
| ||
| Thanks, will take a look over the weekend. |
| ||
| I just want to thank you for your hard work, iminib3d is amazing and absolutely fast! |
| ||
| @SimonH: How can I get this to work in Xcode? |
| ||
| You just need to load up the Xcode project and hit run for whatever target you want to run. |
| ||
| ima747 - I looked into the whole CameraPick/CameraProject thing today again as I had access to an iPad 3, but I still can't see any problem! CameraProject 0,0,20 return the centre screen co-ordinates as it should. Could you post your code? Is it possible you are using a modified version of iminib3d, or your game code is altering the touch-cordinates somehow? |
| ||
| I haven't been back into it in a while. I'll see if I can punch up an example at some point. I am using OS level touch coords rather than iMiniB3D touch coords if that has any effect... I barely even recall the issue since it's been a while but I'll try to dredge it up before WWDC if possible. |
| ||
| Does anyone knows if iMinib3d will work on iPhone5 and iOS6? |
| ||
| Yes it works with iOS 6. Needs a few changes though to take advantage of the extra screen space of the iPhone 5. I'll release an update soon. |
| ||
| Yay, Simon you're still around! Any specific things of note re: Retina 4? I'm going to be diving into updating projects for iPhone 5 this coming week so any major things that need addressing would be nice to know ahead of time if possible. The FOV controlled by the CameraZoom presumably is where I was going to start, have to make sure the OpenGL stuff is the right size... nothing springs to mind as imminently fatal to me besides that to check... |
| ||
| First of all you enable the use of the extra screen space by including a Default-h568@... file in your project. Then a couple of chances need to be made to the current version (0.5) of iminib3d. Firstly, Global::Graphics() is currently hard-coded to the old screen size for iPhones which needs to be changed to match the bounds of the screen. Secondly, the code that currently uses the MainWindow.xib files needs to be changed to not use .xibs, and create a window programmatically that again matches the bounds of the screen. |
| ||
| Thank you Simon, I really appreciate your great work! :-) |
   |