Messages

I was 12, and the internet was just starting up. My brother gave me his hand-me-down computer and also said I should try Q-Basic.

He never got into it himself, but before I knew it, I was recreating the phone call game from Leisure Suit Larry and learning how to make a game with ASCII characters as graphics.

Later discovered an add-on library called Future.Library. It allowed for VGA+higher graphics. I saw a tutorial online about making basic RPGs with drawn tiles. Characters were improvised with filled circle+lines etc... Later found a program that allowed you to draw images in real time, save them and load them, but it had slow performance.

I use texturepacker + polyvector. Works great. Fast and easy to flip/mirror as well.

I create things for one resolution, but I do it using functions which will automatically scale it for whatever resolution. This was my second go at this (first one had animation/scaling/lack of culling problems) and both times it took maybe 2-3 days before I could see stuff working on screen. Had to plan it out before seeing the result.

I'm not very good at explaining what I do and am not familiar with common/official terminology, but I made a video about it a long time ago:

I'm more interested in Mad Catz' MOJO take on this. It has access to the regular Google Play Store right out of the box. I didn't like that Ouya was pushing only freemium games, and even the Unity Ouya SDK is a bit complicated.

http://reviews.cnet.com/consoles/mad-catz-mojo-android/4505-10109_7-35796809.html

I signed up for this awhile back, but from what I could tell, they wanted me to send in an APK for every game individually for pre-approval in the 100%. Then you need to get some voucher code for each game to enable it.

My only problem with publishing on Amazon is that even as a Canadian, they require me to register my company with the IRS. Weird because I never had to do that with Apple or Google.

It won't really tell you anything about implementing different screen sizes. It has a line to activate the autoscaling, and some config options that sets up stretching types (letterbox, fill, prefix/affix for different file resolution). The rest is handled by Corona's internals so it just works, but you won't really know how.

But in general seeing how it creates sprites, display layers, transitions and tweens, click, collision, and how nicely they're integrated, you get an idea of how to set up your whole engine so that everything is extremely well integrated and self managing. Scaling is something you just have to build into these functions but once you got it done, it's off your mind forever (once you get it bug free).

I use Unity for 3D, GLBasic for 2D. Unity is free for mobile publishing now and in terms of 3D there are several pros about it that I could not do without (skeletal animation/physics/collision/scriptable components/shaders) for 3D games. I've grown accustomed to both of them. Also was able to download scripts for Morph Targets which I'd never be able to figure out on my own. The math is beyond me.

I stopped using Corona because it didn't support Z-sorting (only x and y, and layers that are really inconvenient to move objects between), it only published for mobiles, and several other customizations that are only possible if you build all the functions yourself. It was good to learn with though and very feasible for people who just want to make mobile games. But I feel a lot more accomplished making my own framework too.

Thanks for the advice fiink. I haven't used Corona enough to know exactly how it is implemented there. Looks like I should huh?  The difference is that Corona was specifically designed for mobile programming I guess.

Corona itself only builds for mobile, but the inner workings are pretty solid for anything. I'll maybe put up a video briefly showing the framework later and how it handles objects.

I learned a lot from using Corona and I really can't think of a better way to manage objects in a 2D game (but laying that out took a lot of blind work in GLBasic as I couldn't really test it at all until everything was in place). I also added a lot of things I've learned from the forum, and overhauled nearly everything after some major mistakes I made attempting to use my original first version for Ludum Dare 25.

If you've been using Corona's system, you might appreciate trying to reproduce it. Kinda weird to wrap your head around without getting really familiar with Corona, and a lot of groundwork going into it before actually seeing it work (or not work but do something hahaha).

You could start by creating an entity type for the display(s) -- it's good to have multiple layers, which themselves hold an entity type array for objects, which hold information for object type (sprite/image/text), sprite index, size, file path, original scale, new scale, x,y,z, mirror mode etc... and have the main loop automatically cycle through these (resort them in z if there was a modification to that at any point) and draw them every frame. Also it's nice to have a var hold the 1:1 original values.

The scale is taken into consideration in the function that creates the object entity, assigns sprite id, and inserts them into a layer.

I work at a standard size that fits on my monitor and use it as the basis for everything. My engine has universal scaling variables that are determined at the beginning of the program and those are used in every function that requires it to compensate for everything.  Thought I've found it might be best to use the smallest resolution as scaling gets really weird for tiling when you have to deal with upward and downward scaling.

Also using these values, the code should determine an affix for the end of file names ("_2x", or "_4x", or "_0_5x") in the event that you need differing resolution images for larger screens, or smaller ones. Smaller/slower android devices might have trouble running the largest resolution image, so it's better to have multiple sizes. This is the same practice as used in Corona and pretty much everything else, I find, unless you want to use oldschool pixelated graphics.

Maybe it has something to do with "GLBasic files" having a space in it. I don't know why I think that, but maybe that could have something to do with it. If you change it to an underscore, make sure to also modify anywhere that path might appear. Project settings etc... Also clean up again. Maybe even delete the auto-generated folders not a part of your project source and try building again.

Try File -> Project -> Clean Up and then make another attempt.

Just throwing this out there, I think GLBasic with Android doesn't really change the display orientation the expected way. Like sometimes, I find on my games, it's set to render in landscape, but the game is actually still in portrait with a rotated image. Maybe that's one reason the objects are scaling based on the wrong dimensions?

It does look like your objects are scaling with the wrong dimension on the other device. You could try testing for the longer side first and then using that length for the vertical height instead of directly asking for the height.

Back when Corona SDK had a subscription, I duplicated a lot of Corona SDK's commands in GLBasic for my own framework. Comparing Corona SDK to GLBasic, Corona is like a playground, and GLBasic is like tools to build a playground, so GLBasic will enable you to do more, but you have to put a minimal amount of work in to do the specific things that Corona itself includes. You will never be able to fully customize the Corona commands though.

Now that Corona is free, if your goal is mobile, it's hard to recommend against it unless you plan on creating more involving games. It has a very active community and a lot of source implementations are documented.

For me, I like GLBasic because it supports more platforms, and I was able to include z-sorting in my implementation, which frustratingly, Corona doesn't on a per-imagegroup basis. It's kinda of ridiculous since including this didn't take more than one function and a sort. You can use multiple image groups, but you're kinda screwed if you can't minimize your objects in that way or want to do something like a traditional beat-em-up or RPG with a lot of layered graphics.

Box2D works, but without experience in Corona, I wouldn't have any idea how to implement it with my engine in the specific way that I do. Box2D is kinda clunky with both of them, but works better with Corona. You have to disable them on objects before you kill the instances. I actually think Box2D is one of the reasons they're so weird about implementing z-sorting.

I prefer GLBasic simply because in some ways, I know what's going on under the hood and that's especially because I put the work in to make it work the way I wanted it to. If you don't want to do that from scratch (I haven't included everything from Corona, but I added a lot more in other respects) then maybe Corona is the easier route. Corona for example, makes it very easy to scale your games to work on multiple resolutions and devices. That was one of the harder things for me to put into my framework and it's still incomplete in my map tiling section.

Corona is more appropriate for casual games, but that doesn't mean to downplay what you can do with it. The support and existing implementations are very good. I recommend it for beginners that want to code a little and do things a bit manually. I learned a lot from using it, in terms of how to approach building my own engine/framework. For absolute beginners who just want to drag and drop, I might recommend GameMaker. Unity for 3D is a given, no matter what your level, just learn C# and then practice.

--

For the record, both LUA and Basic are easy-to-love. What I use right now is Unity (3D) and GLBasic (2D). I used Corona to publish my first commercial game, but then I needed more (like z-sorting, pc/mac/linux, other stuff) and the limitations made it hard to justify subscribing to at the time (approx. $350 a year to build compared to GLBasic 80 euros one-time).

I got it free from Leap Motion by applying as a developer.

It detects all your fingers (and pretty much any pointing device shaped like one) in 3D space above the device. It seems to knows the rotation and position. It's not a mouse, but I'm sure you could figure out how to use it as one. I've only used it with the visualizer and it seems pretty good. More accurate with fewer fingers just because other fingers can get in the way.

The device gets very warm. Almost hot, when in use.

I was wondering if anyone else implemented it GLBasic because I really don't know much about inlining and time is not a luxury. Unfortunately, I'm not allowed to share the libs.