The next pinball game is underway. Been working the table layout during the Christmas holidays.
This one is a remake (more of a re-theme) of Raster Blaster on the Apple II from 1981. Does anyone remember this one?
Should be out a lot quicker than Bean Farmer. Only a few new elements to create.
Screenshot of the original:
http://upload.wikimedia.org/wikipedia/en/4/46/Rasterblaster.png
Comments
Sorry, didn't really spend any time on the laptop during my vacations, I'll try to look more into Bean Farmer when back home.
Maybe the game you are thinking of could be Night Mission Pinball or David's Midnight Magic.
This gave me the idea that I could add a "capsule" collision type on the editor (using 2 spheres + one box). I wonder if it would work.
You could use a sphere at the top and bottom and a box in between but then you'd have intersecting parts. Not sure what the side effect of that would be.
For those little guys I'm just using a polygon part using all 8 points. It's enough for them.
Pretty pleased with the effect.
And if anyone is interested in following the project on bitbucket, you can find it here: https://gitlab.com/sausagejohnson/rasterblaster
Do you have an .apk I could download somewhere, maybe?
I'll put the video & downloadable beta out next week after I complete the work on the sound effects.
https://bitbucket.org/sausage/rasterblaster/downloads/raster-blaster-reloaded-beta.zip
If you get a moment, download it and give it a try. Any problem or crashes, feedback, I'd love to know.
I particularly like the sound effects!
May I suggest to use left click/right click on the computer version instead of left clicking on left/right side of the table?
The sounds effects were done using a C64 SID VST soft synth. I recorded the effects from the original game, slowed them down to 10% (to maintain pitch) so I could pick out the individual notes. Then recreate the sounds again using the soft synth.
Good idea on the mouse buttons. The click areas aren't really for clicking, they're touch areas for mobile. I suppose I could turn off the mouse with the config? And map to left/right clicks as well.
I also had a crash (assert) at the end of a round in orxObject_GetLastAddedSound(), but I didn't investigate it.
Lastly the right flipper stays stuck sometimes, whereas it never happens with the left one.
So this happened as the ball was lost?
I need to upgrade to 1.6, so will check again. It could be my usage.
How did you manage the stick the right flipper? Does it stay up or not respond? I've never seen that.
As for the flipper, it happens actually quite often but I don't have repro steps. The flipper stays up and the visual circle is drawn but no mouse button is being pressed. Activating the flipper again resets it and everything goes back to normal.
The simplest repro step I found is to start clicking on the left side of the table, move the mouse to the right side, and then release the click there. The left flipper will remain stuck up. That also work if you click, drag outside the window boundaries, and release the click there.
Ah yep right. That's not actually a control. For PC you're meant to use the control or shift keys. This will go when I disable the mouse for PC.
But it is a problem for touch. I need to figure out how to solve this with the touch start/end/move event combinations.
True yes, I am going to fix the polygons to address this. Thanks!
Ah ok, I'll check my functions are working on a valid object.
Question: is it possible to test for an invalid orxObject? I usually set objects to orxNULL before loading them or creating them.
But sometimes if they are not assigned to a valid value, they will have the type of orxObject, but are not initialised. Anyway to test for this? Like testing an internal int within the object for null?
The way to do it is by storing its GUID (orxStructure_GetGUID()). This 64bit value will be unique for an object during this execution of orx. If you want to retrieve an object from a GUID, you can call orxStructure_Get(). If the object isn't valid anymore or if it's not the same one, it'll return orxNULL. It works with any kind of orxSTRUCTUREs, not only orxOBJECTs.
I can't trigger the assert again. I'll try the executable on a few different machines.
A GUID will never be orxNULL. It can be orxU64_UNDEFINED or orxSTRUCTURE_GUID_MAGIC_TAG_DELETED.
If you want to check if an object is deleted, you can do:
Don't call orxStructure_GetGUID() as it's going to mask a part of the value and it won't work. This won't tell you if this object has been deleted and another one recreated in the same spot though.
If you want to retrieve or check if one of your object is still alive, for example to remove a sound you added on it.
Confused though, you said not to use orxStructure_GetGUID() but then used it in the listing.
I also want to test against a fresh object, one that started with a class definition.
Anyway, I'll see how I go.
What I really want to achieve is something like this:
orxOBJECT *object;
orxU64 guid = orxStructure_GetGUID(object);
or
orxOBJECT *object;
orxU64 guid = orxSTRUCTURE(object)->u64GUID;
But of course in both examples, the object is only declared as a type and not initialised.
I want to catch all orxNULLs, uninitialised, and the other two states you mentioned above.
You should use it most all the time, with one exception: when you want to compare its value with orxSTRUCTURE_GUID_MAGIC_TAG_DELETED to know if an object is deleted. But usually you don't want to do that.
I guess I can change the value of orxSTRUCTURE_GUID_MAGIC_TAG_DELETED in the future to removed that limitation.
What you should be doing is never store the pointer to your object. You variable should be the GUID, not a pointer.
When you need to use the object with the orxObject_* API, you should locally retrieve it with orxStructure_Get(), then you can use it but you still should not store it.