Bonjour from Paris, France

Pharap · September 5, 2018, 8:48am

Always an option:

carbonacat · September 5, 2018, 11:05am

AI for Blobby Volley should be easy to do, throwing a few math and maybe some RNG. The real fun of BV was always multiplayer tho, soooo…

Ahah that’d take out some fun if you did, as you’re much more skilled than I am!

For the external button, yeah it’s very simple, yet it’s still a requirement that might not be fulfilled in every situation -like riding a train. So as much as possible, I’d like to make games that only use what the Pokitto provide by default, and then extend them with PEX.

But I got to do it to know best anyway!

As a side note, is there any attempt to establish reliable communication between two pokitto, like the old link cable for the gameboy and so? Unless I buy another one that won’t work much for me, but making it kind of standard (as an optional module from the Pokitto API) could open the following things:

Emulating multiples Pokitto and let them talk for testing by showing both, using differents threads and mapping more keys/controller buttons.
Could be great for education package, as they’re going to have multiple Pokitto already!
Of course, multiplayer games / musics apps!

Pharap · September 5, 2018, 11:25am

As of C++11 you’ve got a whole array of engines to chose from :P

https://en.cppreference.com/w/cpp/numeric/random

This is why we really need to invest in some hats.
If there was a standardised “extra button” hat then you could just tell people “requires the extra button hat” instead of giving them a wiring diagram.

I started trying to connect my Pokitto to an Arduino board but didn’t get around to ordering the 3.3v to 5v bridge.
I have got a spare board so I might just go for it and risk the potential damage, but I’d rather not waste my spare board if I can avoid it.
(Aparently some of the pins are 5v tolerant, but some aren’t, and some are but only under certain circumstances. I’ll check the document again sometime, but it was very confusing.)

I could try to develop something on my spare board, but it doesn’t have a screen so I’d be flying blind (and I’m not sure how well it would run without the screen - it might end up waiting for a response from the screen that never comes).

I hope to acquire a second Pokitto soonish, so maybe I’ll investigate something then.

Really it should be as simple as hooking up N input pins to N output pins.
The trick is picking the right pins (I believe there’s a way to treat multiple pins as a single parallel unit),
and then selecting/devising a decent communication system.
(If I can find some decent docs I might even be able to base it on the GB/GBA link cable.)

carbonacat · September 5, 2018, 2:01pm

Ahhh don’t worry, I’m started using to those engines and distributions for a bit less than a year haha thanks anyway!

Yeah hats definitely deserve time to invest into!

Ah right, that could become handy to try with an arduino first! You could maybe use the debugger for running on the other board? but I don’t know if that’d would even start this way

Zockeromi · September 5, 2018, 2:18pm

Welcome. I am looking forward to your concepts!

FManga · September 5, 2018, 2:30pm

It… does? I never noticed this. It’s a PokittoLib feature? o_O

Maybe change it so the back button (below the reset button) adjusts volume, then you’re free to use the C button.

carbonacat · September 5, 2018, 4:13pm

I hope I won’t disappoint!

Well according to the poster it’s the case!
Maybe it changed and the poster wasn’t updated. I assumed it was somehow hard-wired because its presence on a poster makes it kind of permanent?

Pharap · September 5, 2018, 5:25pm

I’ve looked into them a lot but haven’t actually used them yet.
Oddly I find that I don’t often need random numbers.

I’m tempted to start a thread for hat ideas.
If I had more 3D printing knowledge then I’d try to develop a simple hat.

I’d need to get a debugger cable first,
and I’d probably end up connecting the debugger to the PEX rather than the ports at the back, so it might not be ideal.

I’ll find a way to test someday.
It would be interesting to know if Pokitto boards can run ‘headless’ without modifying the library.

This surprised me to, I discovered it when I was looking into ways to improve the Button library for a v2 of the PokittoLib.

Nope, it’s done in software.

github.com

pokitto/PokittoLib/blob/master/Pokitto/POKITTO_HW/HWButtons.cpp#L145-L150


if (Pokitto::heldStates[BTN_C] && Pokitto::heldStates[BTN_LEFT])
{
    if (!vol_control_clicked) _s.volumeDown();
    Pokitto::heldStates[BTN_LEFT]=0; //do not do normal button operation
    vol_control_clicked=true;
} else vol_control_clicked=false;

jonne · September 5, 2018, 6:42pm

great idea

Pharap · September 5, 2018, 7:09pm

To clarify, the ‘Flash’ button (as it is labelled on the poster, what FManga calls the ‘back’ button),
does it currently only do something if you hold it down while turning the Pokitto on?
I.e. it won’t do anything if you randomly press or tap it while the Pokitto is on?

Because I know tapping ‘Reset’ will put the Pokitto into USB mode.

The only downside I can see to this is if someone tries to adjust the sound but hits ‘Reset’ by mistake.
But it might be worth it.

Funny story: originally I thought ‘C’ was going to be like a ‘home’ button and thought we couldn’t use it in our programs.

Which brings me to one last question: why is it called ‘C’ and not ‘Start’ or ‘Select’?

FManga · September 5, 2018, 7:18pm

Ah, I didn’t know it had a name.

I’ve been using it as a select button in the gameboy emulator, hasn’t caused any problems… though hitting reset accidentally is a risk.

carbonacat · September 5, 2018, 9:57pm

I intended to use the C button solely as a SELECT/PAUSE one.
If it depends on the library, I’d suggest making it the default behavior, and hijack it with a #define. That way we can have the freedom to handle the volume in our own menu systems, and use that button for other things.

Sooo I guess the control scheme for the Blobby Volley game could be the following:

2 Players:

LEFT/RIGHT - Move Player 1’s Blob.
UP - Make Player 1’s Blob jump.
B/A - Move Player 2’s Blob.
C - Make Player 2’s Blob jump.
DOWN - Game Pause/Menu (that’d might have to be strongly) with a nice scroll-down transition.

Game Pause:

UP at the top - Resume Game with a nice scroll-up transition.
UP/DOWN - Select Item
A - Select Option
LEFT-RIGHT - Change current Option’s value.

Hmm yeah, I think I can see this better now. Also could be used for more local-multip games actually. Will still try the A-then-B or B-then-A to jump just for fun

(Also having a weird idea of doing a kind of finger twister but that might end up breaking the pokitto haha)

Pharap · September 5, 2018, 10:52pm

If we ever get round to having a v2 of the library (which I hope we do) then I’d like all settings to be defined by a class/struct type that’s passed as a template argument to the library.
That way to alter the settings you create a new struct/class that inherits the original set with a few modifications.

E.g.

// Library code
namespace Pokitto
{
	struct DefaultSettings
	{
		static constexpr VolumeBehaviour volumeBehaviour = VolumeBehaviour::CAndLeftOrRight;
		static constexpr GraphicsMode graphicsMode = GraphicsMode::Hires;
		// etc
	};
}

// User Code
struct MySettings : public Pokitt::DefaultSettings
{
	static constexpr VolumeBehaviour volumeBehaviour = VolumeBehaviour::None;
};

using Core = Pokitto::Core<MySettings>;
using Core::Display;
using Core::Buttons;

Much more flexible, and it’s done at the language level instead of the preprocessor level.
You can even static_assert for invalid settings.

carbonacat · September 6, 2018, 7:22am

Ah yes, of course templates would be a great things to do for that!