miniB3D
Monkey Forums/User Modules/miniB3D
| ||
| minib3d+monkey https://github.com/adamredwoods/minib3d-monkey big note: - turn on config.h depth_buffer_bits = 32 - tested on glfw, android, macos, ios Works! - normals work - textures, mipmaps work - android, works - vbos and non-vbo fallback works - sprites - batch sprites - context handling for mobile devices - pick (optimized) - collisions - binary load for b3d files (base64) - animation, bone & vertex - Load OBJ - animated textures to do: - fix bugs - MDD, 3DS - thardware - loading progress bar (?) post-release: - opengl2.0 for webGL target - TShader, TShaderBrush - LOD - terrain - object occlusion Most documentation can be found here: http://blitzmax.com/b3ddocs/command_list_3d_cat.php  |
| ||
| Wohoo! Great! |
| ||
| Great ! - binary load for b3d files (will require a hack) Maybe the b3d xml translation I wrote many moons ago could be of use: http://blitzmax.com/codearcs/codearcs.php?code=665 It could be ported or rewritten to BlitzMax (or GLFW?) to create a standalone converter. iMonkeyMiniB3d could read the b3d xml it produces. There is a description of the format here: http://www.blitzbasic.com/Community/posts.php?topic=20674#215167 |
| ||
| Excellent!!!!! |
| ||
| Nice, saves me a job! |
| ||
| That's awesome! Any sources available? |
| ||
| Whoah! How did I miss this thread?!?! |
| ||
| Cant wait to use this, Currently using iMiniB3D (iOS/C++) but would love to use MiniB3D in Monkey |
| ||
| firepaint from the minib3d demos! almost a straight port. sprites work:  ...but it's slow on android: - i'm manually creating mipmaps, may have to send it to hardware. - particles are slow. I even tried an array version versus New Object creation, no speed improvement. :\ - need a routine to reload textures when device is paused/resumed (from a call or something). I'll do Pick, Collision and then upload the source. |
| ||
| Nice. |
| ||
| Sprites/particles were pretty slow in MiniB3D anyway. I think iminib3d had a batched version which was quicker. Cheers Charlie |
| ||
| I did some texture state optimizing and it now runs faster on Android. On to TText-- I don't have a way to DrawText(), couldn't get it to switch back to Mojo for some reason. This will test my cameraProject and unProject since I had to rewrite these anyways. |
| ||
| Are you going to add "md2" animation - I'd imagine it would be worth it for mobile platforms, though I'm speaking from no experience with 3d on mobile platforms... |
| ||
| I'll probably leave other extensions to the community, as it should be possible to port these over from blitzmax. That said, I'll make sure the obj and b3d loaders work. |
| ||
| Any chance of a demo? How is it progressing, will happily assist with testing |
| ||
| Ok, just spent a lot of time on making TBatchSprite class, and no difference of speed on Android (200 sprite particles at 6-7 fps)... blah... this can be improved with opengl 2.0. It did improve particle speed on the PC side though. My guess is all the float multiplies slow things down since static meshes are still relatively fast. |
| ||
| Are you intending to do this with GLES 2? That would be much more interesting... Cheers Charlie |
| ||
| Yes, but the community may need to help out. I want to get the GL20 framing in for minib3d+monkey and then pass it off, as it may be too time consuming for just me at that point. |
| ||
| Keep up the good work , sounding real cool. |
| ||
| Note on minib3d: Binary files don't load natively in Javascript. And I think it may be too much work for me to port Difference's b3d->xml converter for blitzmax, and then back again as a loader in monkey. My other thought is B3D->Base64 ascii files, then back to binary. The zombie.b3d file is about 59k and in base64 is 80k. There are online Base64 encoders. ....thoughts? |
| ||
| Definitely base64. xml is slow to parse and it's large. The only advantage is human readability, which is not really important unless people actually model using Notepad. Right now I'm experimenting with my own format, because the compact ascii formats are either horrible or way too complex for my needs. The other ascii format (obj) is almost useless (no hierarchy, no animations, no proper materials/shaders - .mtls suck). Will see how this goes. I'm also thinking of making a binary version of my format then turn it to base64. |
| ||
| Very cool. I'm looking forward to testing this port extensively with Android! |
| ||
| miniUpdate: TPick works, including triangle on a surface pick. Pretty nice. This took forever. TText works, so now I have 3d text. TBatchSprites works, increasing performance of sprites significantly (with matrix optimizations). What next? - TCollisions, which I will NOT optimize since the code is a mess. I will only get it to a working condition. - TAnimation, reading B3D files from base64. Should be fun. - then I'll release it on github |
| ||
| Good work. I don't envy the task of converting all the collision, er...stuff to Monkey. It was bad enough getting it working in BlitzMax! |
| ||
| What is the lowest version of Monkey this will work on? Lowest version of Android it will work on too? |
| ||
| I'm not using relfections so around monkey52e-53. Android 2.2, using only opengl es 1.1 at the moment. i may plug opengl2.0 later but will always be backward compatible. |
| ||
| Collisions and collision response works. It's very slow on android, so i will look into optimizations after the initial release. |
| ||
| Sounds great! I still like the xml idea, so maybe I can work on that when your source goes online. |
| ||
A familiar face... This means my Base64 loader works for B3D binary files. Animation works, too. Verrrry nice. (in theory you could encapsulate all your files into ONE Base64 file and parse it. Good for HTML5-- when we get to that point) XML would be good too, but I worry about speed. My experiences with XML is that it is slow to parse a hundred-thousand vertices and this would be slow on Android/Java. So i'm almost done. I found a few deep errors, and will need to fix those up. I'm thinking about an MD2 loader (or should I go .X?) to use vertex animation rather than boned animation. This would help on mobile targets. |
| ||
| Cannot wait to start using this Adam, thanks for all your hard work Is it on GITHUB yet, guess not |
| ||
| Great work, the HTML5 version in the future will be awesome... |
| ||
| wow, excellent, great job. I totally stopped on my own engine because I knew this would knock it out the water. Looking forward to messing about with it. What 2D support is there? Have you managed to get Mojo working? What has more support for users to create models with .x or md2? I have never attempted to make an md2 mesh so I would vote for .x but that could be an ill informed choice. |
| ||
| What 2D support is there? Have you managed to get Mojo working? no, but I'm sure Mark will point some things out once miniB3D is released. in the meantime, I set up a switch (EntityFX (n=64) ) that will enable sprites to render without depth testing, which is just as effective. Plus, CameraUnProject works fine (screen -> world), and I've set up a CameraLayer system to render only certain object with certain cameras... this allows for many possibilities, and I put this in to prepare for a shader or fx system to be easily added. |
| ||
| Ah nice! That all sounds very useful! Great job. |
| ||
| Excellent stuff :D |
| ||
| 10 zombies at 3fps, Android + vertex animation..... NOT GOOD ENOUGH! on GLFW, 100 zombies + vertex animation at about  |
| ||
10 animated zombies at 30fps on Android! ( I actually manged 20+ at 30fps) Get your beta-testing hats on, I'm gonna release this beast hopefully within the week. EXCITING!!!! |
| ||
| Looking forward to trying it out! |
| ||
| yeah same, can't wait! |
| ||
| This will be completly awsum :) |
| ||
| Looks great. Really looking forward to 3d in html5 when that gets added. |
| ||
| Woo! |
| ||
| Do you think it would be easy to do a software renderer? There are a few engines available: http://www.kevs3d.co.uk/dev/canvask3d/k3d_test.html http://code.google.com/p/mea3d |
| ||
| Do you think it would be easy to do a software renderer? One of my goals that I wanted (but haven't sufficiently had time) is to pull the render hardware layer into it's own class (TRender) without performance penalties and keep backward compatibility with miniB3D. I got to a point, then realized textures were well entwined. This will have to be revisited, especially for Flash11 and XNA. That said, it wouldn't be hard to replace TTexture with a custom TTexture build using ?target or #config flags. With the TRender class, you should be able to TSoftwareRender extends TRender relatively easily (knock on wood) since no new hardware commands would be needed. This is my preparation for OpenGL20/WebGL. There will be holes, but we'll fill them when we get there. |
| ||
| Can't wait for this. |
| ||
| BETA TESTER Standing By ;-) Can't wait too |
| ||
| Bump |
| ||
| Ack! That bump got me excited; I've been waiting so patiently for this and I thought just for a moment there that the first release must have been posted. >.< |
| ||
| two more bugs need to be squished! hopefully tomorrow, sorry for the delay. UPDATE (march 31): found the bugs! wow, nasty vbo problem i made. but solved and working great. will upload soon. victory song: http://www.youtube.com/watch?v=AZKpByV5764 |
| ||
| minib3d+monkey https://github.com/adamredwoods/minib3d-monkey big note: - turn on config.h depth_buffer_bits = 32 - test on glfw, android, should work on macos, ios ( i can test it tomorrow) 3 examples included: - animation test: 4 zombies, converted from bone animation to vertex animation running at different speeds while aligned to a red cube. you can turn it back to bone animation if you want. zombies in a array so you can go to 999 (slow). on mobile, use two fingers to zoom in/out. try flicking cube. - firepaint 3d: sparks using TBatchSprite, 3d text floating. should reload surfaces on mobile or tablet pause. - pick collision test: paints a sphere red by clicking on its triangles enjoy. i'll list documentation and to dos later. there's a lot in there (like TText, CameraLayers, TPixmap). TRender is now separate so in theory you can create your own software renderer. victory song: http://www.youtube.com/watch?v=AZKpByV5764 |
| ||
| thank you and good job! I'll test this today :) firepaint needs the first line in the OnCreate method to be changed to this to run: SetRender(New OpenglES11) |
| ||
| YOU GOT THE TOUCH BTW how do you turn on the config.h buffer thingy In GLFW the examples crash on: glGenBuffers(6,surf.vbo_id) in TRender.monkey does that mean my hardware isnt good enough? |
| ||
| firepaint needs the first line in the OnCreate method to be changed to this to run Thanks, fixed.does that mean my hardware isnt good enough? under the file minib3d.monkey, turn off VBOs: "USE_VBO=false" i haven't finished the THardwareinfo which would be needed to check opengl abilities. |
| ||
| This is good stuff dude! :) |
| ||
| Brilliant! Just tried all the examples on GLFW (worked fine) and my Android phone (Orange San Francisco aka. ZTE Blade). Quick phone tests... Firepaint gets crippled by new object allocation here, but it seems to animate the sprites just fine when I stop firing, and the 'world' turns smoothly if I disable firing, so I think it should be possible to get it working better with pre-allocated objects. The pick demo is very slow indeed on my phone, but I haven't looked into it much so far. The animation test was a surprise as that keeps near-enough a constant 30 FPS! However, I made it crash with an array index error while trying to pinch-zoom, then it crashed right away when I tried to re-run (same problem), then it crashed after displaying a frame or so... will have to investigate. Still, it really is great to have a new Blitz3D for Monkey, and I look forward to seeing what I can get away with on my phone. Many thanks for all your hard work on this! |
| ||
| so I think it should be possible to get it working better with pre-allocated objects. also try to use just 'tsprite' and 'tmesh' instead of tbatchsprite. i don't know if that would make a difference. The pick demo is very slow indeed on my phone collisions and pick are VERY SLOW. this is a future 'to do' to optimize it. (tech info: i believe this is because Java's JIT does not inline).Also-- be aware that android 2.1 will be slow since it does not have android 2.2 JIT compiler, which improves overall speed. I made it crash with an array index error while trying to pinch-zoom, then it crashed right away when I tried to re-run (same problem) i will look into this too. bugs bugs bugs bugs |
| ||
| Been playing since... excuse my 'personal preference' tweaks, but I've butchered your demos to create a bare-bones template to work from, plus a really simple demo... Template: Simple demo... Fun, though... feels just like the old days of Blitz3D! |
| ||
| Ooh, above demo with update rate set to 60 is silky smooth on my phone... not that it's doing much, but it's very nice! |
| ||
| all samples run nice and smooth at 30fps on my Motorola Milestone 2 *awesome* |
| ||
| Yes! All of the included examples run on my Droid X without crashing, though the touch controls seem to be sporadic and unpredictable and the zombie example takes approximately 40 seconds to finish initializing. No matter, now's my chance to experiment.. So I refactored DruggedBunny's example to try and switch between MiniB3D/Mojo's graphics using Diddy.. it's a pretty bad hack. It seems to run perfectly fine when using GLFW as a target, but the same isn't true for Android; it crashes without a stack trace! I'd love to use Diddy and MiniB3D together! |
| ||
| some issues: 1. i can not use *.b3d, i've exported a *.x out of Blender (2.62) and convert it with DeleD to *.b3d. Then i create a Base64 file with this encoder: http://www.opinionatedgeek.com/dotnet/tools/base64encode/ 2. 2000 vertices per mesh is'nt enough, i've set it to 4000 3. *.obj exported from Blender is'nt textured correctly. No idea why, i've checked many configurations at export but nothing will. I know that it is just a 8 vertices cube, but Blender can show it correctly, also Blitz3D if i export it as *.x hope this will help.... |
| ||
| Awesome work Adam. The animation demo works fine in the iOS emulator, with the others it hangs on: UIApplicationMain( argc,argv,nil,nil ); Giving a SIGABIT error. I think it might be my environment, but will persevere Excellent |
| ||
| ok I turned off VBO's the zombies work great except their right arm is drawn so that it overlaps the torso, like the drawing order is wrong or something firepaint crashes on SetBlend for some reason (from TText.monkey) Picking demo worked fine (if Im sposed to be seeing a white sphere) |
| ||
| 1. i can not use *.b3d, i've exported a *.x out of Blender (2.62) and convert it with DeleD to *.b3d. .. 3. *.obj exported from Blender is'nt textured correctly. No idea why, i've checked many configurations at export but nothing will. I know that it is just a 8 vertices cube, but Blender can show it correctly, also Blitz3D if i export it as *.x if you have examples of files that are not working and can send me the file, send to awpiette AT yahoo DOT com. i want compatibility to be priority. |
| ||
| the zombies work great except their right arm is drawn so that it overlaps the torso, like the drawing order is wrong or something turn depth buffer on, in your local .build folder (glfw): config.h: #define depth_buffer_bits = 32 firepaint crashes on SetBlend for some reason (from TText.monkey) ---- edit: thank you! that is a bug. should be:tex.TextureBlend(2) i will update github Picking demo worked fine click the sphere, should turn triangles red. |
| ||
On a Mac you will need to change the config.txt in the GLFW build folder. The line that needs altering is:OPENGL_DEPTH_BUFFER_ENABLED=true Must say it is very fun playing around with this! |
| ||
| Updated on GitHub: -- (TModelObj) blender texture fix from OBJ file LoadMesh(). should load texture files now |
| ||
| yep all the demos work now. thanks! |
| ||
| The animation demo works fine in the iOS emulator, with the others it hangs on: UIApplicationMain( argc,argv,nil,nil ); Giving a SIGABIT error. I think it might be my environment, but will persevere Everything worked here on MacOS, iOS iphone simulator (latest files, monkey 56b). let me know if you still have problems. |
| ||
| Hi, this generally looks very well, great job :), but I have a problem: models still looks weird. I have Monkey56b but there is no config.h file to set the #define depth_buffer_bits = 32. I turned in config.txt: OPENGL_DEPTH_BUFFER_ENABLED = true, but it still does not work. |
| ||
| OPENGL_DEPTH_BUFFER_ENABLED = true worked for me, |
| ||
| but I have a problem: models still looks weird. which models? do the examples work? how do they look weird, like the zombie arms are on the wrong side (which means depth buffer disabled)? if you're loading your own models, there is still a problem with OBJs, and B3Ds from blender->deled3d->B3D which i'm working on. (please share any models you can giving problems) |
| ||
| Hi, yes, exactly the zombie arms are on the wrong side. Unfortunately OPENGL_DEPTH_BUFFER_ENABLED = true does not work for me (GLFW). My graphics is a GF7300 GT, OpenGL 2.0 |
| ||
| if you're working on the animation_test.monkey example, make sure to change the animation_test.build/glfw/CONFIG.txt file. you can also brute-force it in the main.cpp file and compile using the xcode.project. or you can find the monkey/targets/glfw/main.cpp file and make sure it has the !glfwWindow(w,h,0,0,0,0, CFG_DEPTH_BUFFER_DEPTH ? 32 ...etc...) in it. try brute forcing that file, too, if you have to (may slow down 2d mojo so not a good idea to hardwire it for everything). |
| ||
| Great work! Animation_test gives this error on my 4'th gen iPod Touch running iOS 4.3.5 Both examples runs fine on iOS 5.1 simulator. (http://) whatsdabomb.com/stuff/xc2012-04-06.png |
| ||
| Be sure to check and report on the GitHub issues section: https://github.com/adamredwoods/minib3d-monkey/issues?sort=created&direction=desc&state=open I submitted an issue yesterday: "TRender.ClearWorld() and TTexture.FreeTexture() contain erroneous code." |
| ||
| my guess is memory alignment issues. https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/knowledgebase/docs/kb95.html I wonder if I should just unpack Base64 with INTs to keep the 4byte alignment? This might be a good initial test to see if its the problem. Mark or anyone have recommendations? |
| ||
| I submitted an issue yesterday: "TRender.ClearWorld() and TTexture.FreeTexture() contain erroneous code." yes, I have that fixed, just trying to finish up one more bug then I'll make a git push. |
| ||
| Difference, could you try replacing this Base64 class in moneyutilities.monkey and testing on iOS (not simulator)? Many thanks. |
| ||
| @Adam: Success- Deleting the build directory and replacing Base64 class with the one above makes animation_test run on the iPod. :-) |
| ||
| @Difference - thank you! ************* Updated v0.11 - faster TPick (much faster on android now) - ClearWorld() fix - LoadMesh() for OBJ fixed-- works now with one vertex with multiple tex coords or multiple normals - TText() has a ALIGN_CENTER flag now - Base64 alignment fixed-- works on iPhone, iPad now with ARM alignment issues |
| ||
| nice good job! :) |
| ||
| Just to update; it appears as though ClearWorld() is working perfectly fine now! Here's a little example of Minib3d managed by Diddy screens (DiddyApp3D/Screen3D): |
| ||
| Okay, so perhaps my Diddy example above doesn't quite work right.. if you hold down the mouse on transition: memory access violation. No idea why; trying to figure it out.. Also, I figured that the parent parameter determined which entity a newly created object would always be rendered relative to, but the results seem contradictory to this; The 'fadeSprite' doesn't change position when the camera does. |
| ||
| Actually, a quick glimpse at the module reveals evidence that a child's position should update when a parent moves.. This doesn't appear to be happening with sprites.. I'll test this out. |
| ||
| Actually, a quick glimpse at the module reveals evidence that a child's position should update when a parent moves.. This doesn't appear to be happening with sprites. Should be. simple tests work here. I'll try your example after "Game Of Thrones" is over. |
| ||
| After some testing it does appear to work! The problem was a bit different than I initially thought. To emulate Diddy's transition fade, I threw a sprite directly in front of the camera (Z: 1.0) which is a child of the camera. When moving the camera back and forth, it was flickering unpredictably. Changing the Z distance from 1.0 to 1.00001 seems to completely fix the problem: Also, I think the unpredictable crash on transition while the mouse is held down may be a problem with Diddy (though I haven't been able to replicate the issue on another project yet). Will test further. |
| ||
| Changing the Z distance from 1.0 to 1.00001 seems to completely fix the problem The default camera depth is set to 1.0 to 1000.0, so i can see how 1.0 would cause z-fighting. also try changing the depeth if needed: camera.CameraRange(near,far) |
| ||
| Wow, this is really, really cool stuff! Thanks for that! |
| ||
| Amazing! Thank you very much! OpenGL is probably the best thing that has happened to Monkey since its release. |
| ||
| thanks for the update Adam! Wavefront Obj now works with GLFW, but not on Android. B3D works nowhere. I've tried the Base64-Encoder from http://www.motobit.com/util/base64-decoder-encoder.asp Here is the model as *.obj, *.b3d and base64 in a zip: http://www.sedm.de/monkey/bnb/table.zip and here the source:
Strict
#TEXT_FILES="*.txt|*.xml|*.json|*.obj|*.mtl"
Import mojo
Import minib3d
Class Game extends App
Field cam:TCamera
Field light01:TLight
Field table01:TMesh
Method OnCreate:Int()
SetRender(New OpenglES11)
Self.cam = CreateCamera()
Self.light01 = CreateLight(1)
Self.table01 = LoadMesh("table01.base64.b3d.txt")
cam.PositionEntity(0.0, 6.0, -6.0)
cam.RotateEntity(45.0, 0.0, 0.0)
light01.PositionEntity(0.0, 6.0, -6.0)
light01.PointEntity(table01)
AmbientLight(30, 20, 0)
SetUpdateRate(60)
Return 0
End
Method OnUpdate:Int()
Return 0
End
Method OnRender:Int()
RenderWorld()
Return 0
End
End
Function Main:Int()
New Game()
Return 0
End
|
| ||
| ok, i've tried this with several objects. The Object Loader doesn't work on Android |
| ||
| ok updated the OBJ loader for android, but i'm still working on the B3D loader error and a couple other problems. |
| ||
| woohoo! Thank you! |
| ||
| the LoadB3D bug was nasty, but it's squished. B3D files should work now, tested on glfw, android. I'm getting my OSX Lion upgrade in the next week so will be able to test iPad soon, but should work regardless. UPDATE: the bug was nasty, so it may help fix other crash issues. |
| ||
| currently i write a Blender 2.6.x export plugin for *b3d files with the option for an export as a Base64 encoded text file ... wish me luck ;) |
| ||
| bruZard, GOOD LUCK! I am really looking forward for this kind of export plugin ;-) |
| ||
| @AdamRedwoods: Thank you for doing this module! As an early Blitz3D user I can't be more happy now! :D |
| ||
| @visionastral You're welcome, glad you're interested! UPDATE v0.14: Animated textures, a few texture fixes. Added: TBrush.LoadAnimBrush(file,flags,frame width,frame height) Added: TEntity.AnimateTexture(frame:int,loop:bool,index:int=0)
''example
''OnCreate
bru_explo:TBrush = LoadAnimBrush("explosion_rgb_sheet.png",9+2,100,100)
sprite_explo:TSprite = CreateSprite() 'could also use TBatchSprite
sprite_explo.PaintEntity(bru_explo)
''OnUpdate
frame += 0.5
sprite_explo.AnimateTexture(frame,True)
I also modified TTexture frames so they would not create new textures but rather animate using texture position and scale. This is handled automatically, just a behind the scenes change. AnimateTexture() is a shortcut to animate the current brush texture if frames are present. Option for looping. I also added uv alteration info to brushes, which deprecates uv alteration in TTexture (but it still can be done), so that EACH brush/surface/entity will have independent animation for textures. THIS IS DIFFERENT from the Blitzmax version, but in my opinion makes Brushes more powerful. I added a command "PaintEntityGlobal(bru:TBrush)" just in case someone needed to animate or change textures on a global brush level. ALSO: Added TRender.GetVersion(). Returns Float value for render (opengl) version checking. Tested on PC, Android, will make sure Mac, iOS work later. I'm sure these changes will cause new bugs, let me know when you encounter them. Also, if you think these changes are too extreme, please let me know for discussion. |
| ||
| THANK YOU!!! |
| ||
| I'm glad to see this project is up and alive! OpenGL is not the kind of language fitted to everyday programming! I was asking myself if the blitz 2D functions could be ported too, since opengl allows us to access custom buffers and I suppose we have full access to opengl buffers, doesn't it? however I don't know how fast would it be... What do you think? is it realistic? Making a full blitz3D port to monkey would be amazing! :) |
| ||
| What do you think? is it realistic? You are welcome to add to this module, but for me I'd rather get mojo working on top of miniB3D for 2D needs, since remaking blitz2d would take me forever. |
| ||
| Mojo is ok for me, but since miniB3D is using OpenGL I thought it was problematic to use mojo at the same time. I don't really have tried much, but when I did (a few days ago), using mojo and opengl together would make each other frame buffers to be deleted and ultimately causing crashes. (that was my experience, perhaps I wasn't doing things correctly?) That's why I thought about making a B2D extension, in order to make it work nicely with opengl mode. But if I can make mojo work well along with opengl, then this is the best way to go, of course. -edit- BTW, is the monkey miniB3D fully compatible with the BlitzMax version? I would be interested in making my level editor in bmx but since the engine would be made in monkey, it would be nice if I just could copy-paste the engine's code from monkey to bmx (as the code is very very close from monkey to bmx as long as you don't use functions not present in bmx) |
| ||
| Mojo & miniB3D: my hack "RestoreMojo2D()" works for glfw, but not for android so far. example: '' in OnRender() glBindBuffer(GL_ARRAY_BUFFER,0) ' this helps reduce crashes glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0) RestoreMojo2D() glDisable(GL_DEPTH_TEST) glDisable(GL_LIGHTING) SetColor 255,0,0 DrawOval( 100, 100, 200, 200 ) SetColor 255,255,255 glEnable(GL_DEPTH_TEST) glEnable(GL_LIGHTING) BTW, is the monkey miniB3D fully compatible with the BlitzMax version? no. i've deviated from minib3d, but they are compatible with a couple of minor adjustments. since minib3d+monkey had to be multi-platform, this brought up a whole slew of restrictions. |
| ||
| works for glfw, but not for android so far. At least I can use the ChallengerGUI with OpenGL on windows, mac and linux with your hack. Thanks! By the way, why is this happening anyway? I mean, mojo is using opengl too (except in flash and xna) so why is this happening? |
| ||
| Thanks Adam for your continuous work! :) Having the mojo 2d set would be great! |
| ||
| I noticed something weird: In your examples, this line is making the app crash 50% of the time: txt.SetText(fps+" fps ~nhow are you",0,0) I have noticed it's because of the "~n" new line character. If I delete it, then it never crashes. That's very weird, specially because it doesn't crash every time, but only 50% of the times or so... Perhaps it has something to do with the fps counter, I don't know. - edit: By the way, I'm compiling for GLFW when this happens - |
| ||
| It's that time again... Continued here! |
   |