Game dev question


#21

Unlimited code size, but probably only fast enough for visual novels or something.
Sigh, there goes my compo entry… :stuck_out_tongue:


#22

Please no. I’m only joking you know. @jvdw007 will be just fine with 70kB


#23

Wow. Talkative :slight_smile:
I’m sure 70kb is enough for most ideas. I just need to curb my enthusiasm for wanting to create grander games is all :slight_smile:

All I was really trying to say is that it is a pity that sound and graphics data eats up code space.


#24

That or learn a new programming language… I’ll just leave this here…


#25

@jvdw007, meet Pharap, our resident Mr Miyagi. Doesn’t beat about the bush but is very helpful and friendly!

@Pharap, I hope you’re OK with the introduction :hugs:

Now, wax on, wax off. Repeat.

Only when resources run out, real resourcefulness is found!

tenor


#26

Oh. Well, I got a quick proof-of-concept going (“running” isn’t the right word), printing some text on the screen. It is really slow, but looks promising for text adventures. Maybe with the occasional 16-bit image to illustrate a scene or for UI or something. Definitely no animation. Zork remake, anyone?


#27

Alternatively codefucius. :P

I think you’re putting me on too much of a pedestal here.
I’m still 100 years too early to be compared to Miyagi-sensei. :P

I’ll take helpful and friendly though, I strive to be those whenever I can be.

Is that an actual quote or have you just coined it?
Either way I’m keeping it. It’s almost zen enough to be a koan.


How long until we have Ren’py support? :P

https://www.renpy.org/

More seriously, forget this and work on your jam entry,
you’ve contributed plenty of tools already, it’s time to work on something selfish for a change. :P


P.S. My suggestion about learning C++ is completely biased. C++ is one of my favourite languages and I enjoy answering questions about it. I find we don’t get that many people asking questions about C++ and/or programming.


#28

Sounds plausible, though it’d have to be done by someone who actually knows Python (not me!)
Before building, a python script would use their parser to convert rpy scripts into micropython and resize/convert the images.

Forgotten already, I just needed to get the “is this possible?” question out of my mind so I could work on something else.


#29

Hey give me a break! I just STARTED to learn Micropython… One language at a time please!!! :slight_smile:

I really like it for the simplicity compared to C++. For now, I just want to make games how I can. I will eventually get to the point where I will need to move up to C++ to get any further, but for now, I’m having fun and just trying to get as much out of what I have available to me.

Ultimately, I think I’d like to get to a point where it would be possible to load levels/graphics in from the SD card to be used in the game code, but since I’m not anywhere near familiar with C++ or the true capabilities of the Pokitto, I’ll try stick with simple(ish) games for the time being.

@jonne I really like that quote too and I hope it reminds me to try be more resourceful when things get tight. I do generally try to write reusable code and try to make things more efficient. I think if you look at the code for Pokaquarium compared to Pokittobloids, you’ll have noticed I have slightly improved a bit. And that’s the hill we all climb to a degree: constant improvement…

I do wish that the Python adaptation for the Pokitto could expose more functionality that C++ can get to though… :zipper_mouth_face:


#30

Specifically which parts of it are more simple?

Of the features that both C++ and Python have,
I find C++'s equivalents tend to be just as simple most of the time.
Most of C++'s complex features tend to be features that Python simply doesn’t have.

(Like templates. Though I hesitate to say those are complex - some templates are indeed sprawling beasts, but others are incredibly simple).

The SD card functionality is the only missing Pokitto functionality as far as I’m aware.

I’ve only used micropython once or twice though, so there might be a lot of stuff I’m not aware of.
The lack of certain features that regular Python has and the lack of library documentation kept me from attempting any more with it.

You’ll never have all the functionality that C++ has though, simply by limitation of the language.
Python is interpreted, so there’s less room for compiler optimisation,
and it’s fully ‘garbage collected’ so all objects end up on the heap,
whereas C++ is fully compiled so it has more room for optimsatio,
and it gives you more options for where your data ends up.

A C++ variable might well live in a CPU register rather than needing to be kept in memory like a Python variable does.


#31

Which features you are thinking of?


#32

Syntax for one. I’m not a fan of syntactically complex languages.

If I understand this, I guess it means you can externally load more data into your program? If so, then this could really help get more out of 70kb space left.

More granular screen mode options for one. Ability to play 11khz music for another. Talking of, are there any options for matrix/scaling images or rotating images?

Look, I’m not complaining. The online IDE is excellent and serves my purposes well so far, but has limits.
It’s also frustrating, as it VERY regularly hangs the browser tab, so saving to a zip file is a must all the time.

Coming back to @Pharap loving C++. I’m sure it’s magnificent, but I’m trying to learn and get better at Python. That is my goal for the next year or so. Starting off with Micropython is a great intro into that, and moving beyond the capabilities of the Pokitto version of it will mean I’d need to move onto other platforms that provide more full fat Micropython support and eventually I will use Python proper. I suspect I’ll be aiming to adapt my games for the Raspberry pi and Clockwork Pi but I’d need to learn and know more about Python in general to get there, IYSWIM.


#33

Which part of C++'s syntax is ‘complicated’?

All I can think of is function pointers and certain more advanced uses of templates.

Yes it can do that, though I’m not entirely sure how it would work in Python.

In C++ you just read the SD card data into a RAM buffer and then use that as you please.

Presumably in Python it would have to be read into a list somehow.
(Or a bytebuffer if such an object exists. I believe bytestrings are actually stored in progmem and can’t be written to, but I could be wrong about that.)

Either way it’s pretty slow, so to be effective you’d have to use it for something like level loading -
something that you can load in ahead of time and keep around for a while.

‘Granular’ in what sense?

I’m not sure what modes are currently implemented,
but in my opinion the most useful modes are:

  • 110x88, 16 colours - 4,840 Bytes (~4.7KB)
  • 110x88, 256 colours - 9,680 Bytes (~9.5KB)
  • 220x176, 4 colours - 9,680 Bytes (~9.5KB)
  • 220x176, 16 colours - 19,360 Bytes (~18.9KB)

(In order of size rather than usefulness)

There’s no GPU whatsoever.

The only advantage to adding those to the Python API would be that they might achieve better performance if implemented in C++ rather than Python.

But even then, I’m not sure vectors and matrices are the most performant way to do 3D rendering on Pokitto (assuming that’s why you want them).

Part of the reason I was pushing C++ is that I thought your objective was to write games for the Pokitto rather than learning Python.

If your objective is learning Python then personally I think you’d be better off just using pygame right off the bat and then working backwards towards using fewer features.

The Pokitto’s Python capabilities will always be limited due to RAM and ROM constraints, there’s no getting around that.

Like I say, Python comes with a decent chunk of overhead.
That overhead isn’t as significant on a desktop where you’ve got whole gigabytes to go nuts with,
but it makes a big difference on a system that doesn’t have even 1MB memory in total.

Other people may disagree, but personally I’m not convinced that interpreted langauges are a good fit for embedded systems unless the system has enough memory to be toeing the line between embedded system and ‘proper’ personal computer.

There might be some exceptions, e.g. maybe languages like Pawn,
but the majority come from the 90s and expect at least a 90s spec.
(Python is '90, Lua is '93, Ruby is '95, JavaScript is '95 …)

I’m not really sure you would.

The API for interfacing the device changes, and perhaps the data (image and sound) formats,
but the rest of the code that implements the game’s actual logic probably wouldn’t need to change.

Unless their APIs are using some technique or feature that the Pokitto API isn’t,
then porting should be mostly a matter of swapping out data and specific function calls.


#34

AFAIK it’s only the default low res 16 col and a high res mode which appears to be the 4 colour mode.

That’s exactly what I was thinking. Being able to load in levels which could be data, graphics or otherwise would’ve been nice :slight_smile:

With regards to matrices, I was thinking more along the fact that if you could scale graphics, you could save space/data by using existing graphics for effects instead of having to draw more/individual frames for said effects, like for example an explosion. Not a biggy at the end of the day, just a nice cheap way of achieving some results.

My objective has always been both to learn Python, but also make games for the Pokitto, as it’s a brilliant handheld for playing games. Being able to use a language to make games easily for it is the cream on the cake for me, hence why I love the combo.
I’m sure I will eventually move to C++ as that is also a long term goal. But for now, Python is my target.

That is what I still need to investigate, but that’s a new year’s resolution for 2020 :slight_smile: At the moment, I’m loving making games for the Pokitto and playing them. That’s all I need right now.


#35

Scaling isn’t as simple as just using matrices.
Matrices only work for scaling if you’re rendering sprites as scalable quads.

None of the built in functions scale sprites because it’s difficult to make scaling look good,
even when you aren’t limited to a fixed-size palette of colours,
and even if they did it wouldn’t necessarily be quad-based rendering.

There’s no GPU here after all.

For an explosion you’re probably better off with a particle system anyway,
so you have lots of little smoke clouds coming out from the epicentre instead of just one big blob of cloud that grows large.

It uses more RAM, but it’s probably slightly faster than a scaled sprite would be (depending on how many particles you have),
and it has the potential to look better anyway.

Particle systems are what pretty much all the well known games use.

I can think of a few examples that use pre-generated frames.
(Mainly top-down 2D Zelda games like Minish Cap.)
But I’m not aware of any that actually do sprite scaling.
(At least as far as I can think of at the moment. I might remember one later.)

I honestly get the impression that you think C++ is a lot more complicated than it actually is.
The basics at least are not particularly more complex.

When it comes down to it, pretty much every procedural language has variables, ifs, whiles, fors, bools and function calls.

It’s only when you get into data structures, libraries and other more advanced features (e.g. Python’s metamethods versus C++'s operator overloading) that languages start to diverge.
(Ignoring syntax of course, though that’s rarely an issue.)

That’s the last I’ll say of it for now.


#36

Currently there are only mirroring vertically and horizontally, which is very fast also.

I think MicroPython (and C++ as well) in Pokitto is a very nice way to learn the language and to learn game coding in a constrained system. MP brings its own limitations which makes you invent more clever (and fun) ways to overcome those.

IMO, people may think Python looks more “friendly” because there are e.g. not so many “{}” or “;” chars as in C++. Also the online editor makes Python easily approachable in Pokitto.