Forum Replies Created
-
Posts
-
I see what you mean, but there’s no easy way to do this. Bullet objects aren’t bbObjects so they can’t be GC’d. If mx2 had finalize(), you could theoretically wrap the entire API so peer bullet objects were deleted when mx2 objects went out of scope, but as yet there is no finalize. This would also introduce overhead, both in terms of GC work and going through a wrapper for everything.
Besides, what about code like…
12345For Local i:=0 Until 100Local body:=New btBody(...)world.addBody( body )Next…probably not a good example of real world code, but still, you’d have to pretty careful about keeping objects alive!
I think the simplest/cleanest/fastest solution would be to implement something like ‘DeleteWorldAll’ in glue code that enumerates everything in the world and deletes it before deleting the world itself, plus if necessary variations of, eg: DeleteWorldBodies etc. Bullet already tracks all this stuff anyway so it allows you to work directly with native objects without any additional GC/wrapper overhead. Leaks can happen if you forget to add something to a world, but this is kind of the opposite of forgetting to remove something from the world before it goes out of scope – except in the DeleteWorldAll case you’ll probably just leak as opposed to crash.
Fix pushed to develop – I’m in clean up mode!
Email it to me and I’ll add it to the repos/distros – we need more themes!
I’ve also just pushed a fix for the ‘close button margin’ issue to the develop branch. Margin’s weren’t meant to be included in a view’s ‘hit zone’ but it looks like they were. Should be fixed now, and hopefully doesn’t mess up anything!
Bullet is one of the first c++ libs I want to try and mx2-ify once c2mx2 can handle c++, so you might want to hold off for a bit!
however I was directly linking to a pre compiled version of the library.
I avoid this by #importing the library c files in a .monkey2 file – see: sdl2/makefile_windows.monkey2 etc. There is no automated way to generate this list of c files yet, but “dir *.c >t” can be a good starting point!
This does mean you sometimes have to tweak config.h files along the way as configure/cmake based systems often generate different config.h files per target, but I think it’s worth it to get everything building with the same build system.
I’ve done this with both ODE and bullet (and a ton of other libs) in the past, but with c++ projects. However, the basic idea is the same – the library c files just become c files in my project.
it will also mean that the user will have to be responsible for deleting physics instances (far from ideal) unless I can figure out the GC system
IMO, leaving it up to GC to delete physics entities is not a good idea anyway – when you want to delete a rigid body, you want to delete it *now* or it’ll continue to affect the simulation. Your code may have dangling references to stuff that don’t get nulled or overwritten for a while, and even then the incremental GC system may delay deleting things until some random time in the future. Best to bite the, erm, bullet here and just use Destroy().
Ctor and dtor example:
1234567891011121314151617ExternClass Blah Extends VoidMethod New() 'ctor!Method Destroy()="delete" 'dtor!EndPublicFunction Main()Local blah:=New Blahblah.Destroy()EndActually, looks like there’s a monkey2logo.svg in src/launcher!
Are there any plans for Monkey2 to support UWP, more specifically XB1 retail consoles in dev mode?
There are no plans for any new targets right now. Each new target adds a considerable amount of extra work and I’m pretty much running at maximum capacity here!
Does the mojo2 Spine module currently work in Monkey2?
No idea, but it should be easy to convert. There is an ‘experimental’ monkey2 spine module but unfortunately it’s not open source so I can’t include it in the monkey2 release. It will need to go on a ‘special’ download page here as I am apparently required to include the license on the same page as the link, but I haven’t got around to it yet. In the meantime, I can send you the monkey2 code if you want, you’ll need to drop in the ignition C code from github yourself.
How far along is development in terms of export targets? ie. Can it currently export to iOS/android?
It can but these are fairly incomplete. They can handle the monkey2 side of things fine, but there are no monetization etc modules yet (hard) and you can’t yet build for multiple architectures (easier).
How viable is it to start a proper project in Monkey2 as it stands at the moment?
This is of course a really subjective question, but IMO very viable. The only major ‘gamey’ thing I think it’s missing (if I were to write a game that is…) is the ability to stream music, something I plan to fix soon.
I like the idea and had a hack at adding Richard’s logo to the ‘new….simple mojo app’ template, but it looked pretty washed out on the medium grey default window background. Looks great on black, but I’d like to still with ‘grey’ for the default.
Ditto, the pink monkey above looks a bit rough on ‘charcoal blue’ or whatever color the forums now use!
I think for starters a logo will need at least a border + solid background color, so it can be safely used on *any* background. Perhaps a slightly toned down version of the ‘monkey circle’ above?
I’m still open to ideas regarding logos etc, but I do also like to give things a try for a while before discarding them.
I’ve had a go at fixing some of these issues.
The ‘wont draw after creating a maximized window’ issue is weird, I’ve hacked around it for now by forcing 3 App.RequestRender’s after opening such a window which works here. There’s no reason it shouldn’t be drawing, I’m guessing the SwapBuffers isn’t working but you can’t check that for failure!
Added some new event types: WindowMaximized, WindowMinimized and WindowRestored, some properties: Maximized:Bool and Minimized:Bool and some methods: Maximize(), Minimize(), Restore().
The new event types are always preceded by a WindowResized, so you can generally ignore them.
There seems to be a bug in SDL on linux where maximized, minimzed etc. events are only generated when the user interacts with the window – not when you can Maximize() programmatically. May fake around this later…
I also began work on a better fullscreen system. The Fullscreen property is now read-only, and you need to use BeginFullscren()/EndFullscreen() to go into/out of fullscreen. I’ve done it this way because there are several ways you go can into fullscreen, eg: BeginFullscreen() to go into ‘desktop size’ fake fullscreen mode, BeginFullscreen( w,h,r ) to actually change resolution – and there are likely to be more once you can enum display modes. A simple bool just isn’t enough to enable fullscreen. Plus, I’d also like to add some methods for changing res while in fullscreen…
There also appears to be another bug in SDL where you can’t go from a maximized window into ‘real’ fullscreen (on windows anyway) so be aware of that for now.
Excellent!
I’m holding off until I add ‘overloaded’ classes before adding class where.
It’ll still work without the where, you’ll just get different errors if you do the wrong thing (ala c++). Since there is only one possible ObjectListView<T> class, where can’t help ‘select’ an overload to use the way it can with functions.
Actually, before trying that you might want to give this a go – does it give a clean gradation of red in the lower half (top half yellow)?
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899#import "<libc>"#import "<sdl2>"#import "<gles20>"Namespace sdl2testUsing sdl2..Using gles20..Class SdlWindowField sdlWindow:SDL_Window PtrField sdlGLContext:SDL_GLContextMethod New()SDL_Init( SDL_INIT_VIDEO )libc.atexit( SDL_Quit )SDL_GL_SetAttribute( SDL_GL_CONTEXT_PROFILE_MASK,SDL_GL_CONTEXT_PROFILE_ES )SDL_GL_SetAttribute( SDL_GL_CONTEXT_MAJOR_VERSION,2 )SDL_GL_SetAttribute( SDL_GL_CONTEXT_MINOR_VERSION,0 )SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER,1 )SDL_GL_SetAttribute( SDL_GL_RED_SIZE,8 )SDL_GL_SetAttribute( SDL_GL_GREEN_SIZE,8 )SDL_GL_SetAttribute( SDL_GL_BLUE_SIZE,8 )sdlWindow=SDL_CreateWindow( "SDL2 OpenGL Window",SDL_WINDOWPOS_CENTERED,SDL_WINDOWPOS_CENTERED,640,480,SDL_WINDOW_OPENGL )sdlGLContext=SDL_GL_CreateContext( sdlWindow )SDL_GL_MakeCurrent( sdlWindow,sdlGLContext )EndMethod Run()RepeatLocal event:SDL_EventWhile( SDL_PollEvent( Varptr event ) )Select event.typeCase SDL_WINDOWEVENTLocal wevent:=Cast<SDL_WindowEvent Ptr>( Varptr event )Select wevent->eventCase SDL_WINDOWEVENT_CLOSElibc.exit_(0)EndEndWendOnRender()SDL_GL_SwapWindow( sdlWindow )ForeverEndMethod OnRender()glClearColor( 1,1,0,1 )glClear( GL_COLOR_BUFFER_BIT )glEnable( GL_SCISSOR_TEST )For Local y:=0 Until 256glScissor( 0,y,640,1 )glClearColor( y/256.0,0,0,1 )glClear( GL_COLOR_BUFFER_BIT )NextglDisable( GL_SCISSOR_TEST )EndEndFunction Main()Local window:=New SdlWindowwindow.Run()EndOK, just pushed a possible fix to the ‘develop’ branch.
Nice!
Woah, 4 bit color!
Will investigate…also, what OS/graphics card are you using?
