CocosBuilder is a brilliant tool that helps you rapidly develop Cocos2D applications.
But the latest versions require the Cocos 2.x branch.
Some of us are stuck with Cocos 1.x for the time being. So let’s figure out how to get things going.
So here is a semi-live blog as I delve into Kivy.
Ok let’s start at the start.
We first create an object that inherits from App. Done.
Ok, and the examples all return a widget from the App’s build() method. So we don’t over-ride __init__… ok… thats… unique.
Perhaps the widget is the window if it is returned from the build() method?
Widget is not the window. Widget returned from build() is added to the window. So… where is the window created?
Window docs state the window has a constructor that lets you set the window size. Ok, cool. But we don’t create the window… so.. we can’t use the constructor… sigh.
Ok, Window has a static accessor.
kivy.core.window.Window = None
No comment on what is stored here but I assume it’s the instantiated window. It doesn’t mention when it is set… handy!
Only 1 window allowed. Ok… weird. Well… let’s try that.
AttributeError: 'module' object has no attribute 'window'
Let’s scour the code.
No Window.py file……… how far does this rabbit hole go.
Ok, let’s check out the __init__.py file in the window module.
class WindowBase(EventDispatcher): '''WindowBase is a abstract window widget, for any window implementation.
So… window base is in there. Feel free to scream now.
So we can get this by importing kivy.core.window and just leaving the class off the end.
import kivy.core.window ... def build(self): print kivy.core.window.Window.size return None
Ok sweet, thats our window.
So let’s change its size.
def build(self): print kivy.core.window.Window.size kivy.core.window.Window.size = (1024, 768) print kivy.core.window.Window.size return None
File "/Users/adamgriffiths/Workspace/VirtualEnvs/progress_quest/lib/python2.7/site-packages/kivy/core/window/__init__.py", line 243, in _set_size if super(WindowBase, self)._set_size(size): AttributeError: 'super' object has no attribute '_set_size'
Ok, so after some googling we find this post about the relationship between the App and Window classes.
His solution is to pass the size as a command line parameter……….. LAME. That kinda throws the whole configuration settings thing out the window.
Looking through the Kivy code we find this block inside their base window class’ __init__ method.
if 'fullscreen' not in kwargs: fullscreen = Config.get('graphics', 'fullscreen') if fullscreen not in ('auto', 'fake'): fullscreen = fullscreen.lower() in ('true', '1', 'yes', 'yup') kwargs['fullscreen'] = fullscreen if 'width' not in kwargs: kwargs['width'] = Config.getint('graphics', 'width') if 'height' not in kwargs: kwargs['height'] = Config.getint('graphics', 'height')
Ok, so we can try and set it via the global config object.
So let’s add that to our App class.
def build_config(self, config): config.adddefaultsection('graphics') config.setdefault('graphics', 'width', 1024) config.setdefault('graphics', 'height', 768) config.set('graphics', 'height', 1024) config.set('graphics', 'width', 768)
Run the code and……
So let’s put some debug INSIDE kivy and see what is happening. We’ll also force it to pull the ‘graphics’ setting and ignore kwargs.
if True: #'width' not in kwargs: kwargs['width'] = Config.getint('graphics', 'width') print kwargs['width'] if True: #'height' not in kwargs: kwargs['height'] = Config.getint('graphics', 'height') print kwargs['height']
And the output…
Hmm.. ok, this post on the kivy-users forum (because documentation is for lusers) shows a similar method.
They use the Config module directly instead of the config object passed to App….. because….. they’re not the same? Well.. let’s try it anyway.
from kivy.config import Config Config.set('graphics', 'width', 1024) Config.set('graphics', 'height', 768)
And our output
Ok, weird because the window HAS ACTUALLY CHANGED SIZE.
Whatever. We’re all living in crazy-ville atm so let’s just pretend everything is normal.
So let’s move that inside our build_config() method.
def build_config(self, config): Config.set('graphics', 'height', 1024) Config.set('graphics', 'width', 768)
And the output
[INFO ] Kivy v1.1.1 [INFO ] [Logger ] Record log in /Users/adamgriffiths/.kivy/logs/kivy_12-03-22_40.txt [INFO ] [Factory ] 102 symbols loaded [INFO ] [Text ] using <pygame> as text provider [INFO ] [Loader ] using <pygame> as thread loader [INFO ] [Window ] using <pygame> as window provider [WARNING] [Window ] Unable to use <pygame> as windowprovider [CRITICAL] [Window ] Unable to find any valuable Window provider at all! Fatal Python error: (pygame parachute) Segmentation Fault Abort trap: 6
FM transmitters on the same frequency clash and quite often SWAP the audio in 2 cars.
My favorite thing is to leave my FM transmitter on my phone at the default frequency of 88.1 and play crazy zombie music while I drive around.
I listen for audio clashes and look around for the person who is totally confused as to why their iPod has become possessed.
Even better is when you can hear their songs and they start to rapidly change as they frantically try to fix it.
Murtle76 not only hates a game he didn’t bother to play, but insists that he isn’t insulting or annoying anyone…
This discussion regarding Borderlands pricing differences, although not a big deal this time, is the latest in a long line of regional pricing FUBARs.
I saw that Borderlands standalone (US$7.49) and Borderlands GOTY edition (US$7.50) were both on the “Top Sellers” list.
I thought perhaps people were boycotting the DRM encumbered DLC for the game (included in the GOTY edition), which made me happy!
Then I checked the forums and realised I was wrong. Different regions, again, have vastly different prices:
Borderlands GOTY = $7.50
Borderlands = $4.99
DLC = $7.49
Borderlands + DLC = $12.48 (greater than GOTY by $4.98)
Borderlands GOTY = $7.50
Borderlands = $7.49
DLC = $7.49
Borderlands + DLC = $14.98 (greater than GOTY by $7.48)
Borderlands GOTY = £7.50
Borderlands = £4.99
DLC = £4.74
Borderlands + DLC = £9.73 (greater than GOTY by £2.23)
Borderlands GOTY = €12.50
Borderlands = €4.99
DLC = €5.99
Borderlands + DLC = €10.98 (less than GOTY by €1.52)
As you can see, this pricing is literally schizophenic.
I don’t believe this is Valve (although their Steamworks page does say that they will suggest pricing for games), I think this is the publishers stepping up pressure on Valve to fall into line. And unfortunately it’s working.
I made a comment that perhaps we should all band together to make a “Steam Gifting Co-operative”. Thing is, I was serious.
Many deals in Europe or the AU are far inferior to the US pricing. The region banning is stupid. This usually isn’t Steam but government ratings forcing publishers to offer modified versions (eg. L4D2 with fading out corpses instead of normal version). Grand Theft Auto: Vice City is still NOT on steam in Australia (thanks guys, you forced me to pirate it) although GTA3 and GTA:SA finally are.
Gifting gets us around this. It can also get us around the price issues. The only problem I can see is something like this happening if the “giftor”s bank account goes into the negative. Which is pretty horrific.
People would be re-imbursed for gifts (this isn’t a charity!). The only problem is ensuring that the “giftee” pays the “giftor”. Most bank transfers take a day and by then most deals would be over. I believe PayPal transactions are instantaneous, but I’m not sure. If it is, this would negate this issue.
I think a gifting co-operative is a very realistic and simple way of negating some of the publisher’s influence on Steam.
There needs to be a way to:
DRM doesn’t fucking work!