Hi friends,

My next project is likely going to need to rotate sprites, so I've been looking at the various methods posted on the bbs. Something I'm wondering about while I've been looking at everyone's examples is, how does one approach collision detection for when a sprite is rotated?

I'm currently capable of AABB and bitmasking per row of pixels, but it seems I'm going to have to write some new methods to integrate either of these into a rotation algorithm, and I'm not sure where to start. I'd appreciate any links to any carts or non-p8 articles or anything, really!

CPU is also a concern for me, as I think I'm going to need a lot of it dedicated to drawing the backgrounds I need which would be rendered via something like spellcaster's rle library.

Thanks in advance! :)

EDIT: See the first reply below if you'd rather compile and use the native tool, which does seem more streamlined!

Hi, friends!

I just put Pico-8 on my Raspberry Pi for the first time and ran into problems getting my USB gamepads to work. Unfortunately, there's no ARM build for the General Arcade SDL2 Gamepad Tool, and I didn't want to bother with compiling the native helper, so I had to take this manual route. This will only take you a couple minutes.

The final SDL string will look something like this:

---

First, let's get the GUID.

This issue in the GameControllerDB repo tells us a little bit about the GUID structure in SDL 2.0.5+. It varies between operating systems, and so if you copied it from a different OS to Raspbian, this might be the cause of your woes (as it was mine)!

Open a terminal and run:

$ cat /proc/bus/input/devices

You should see your device listed in the output. We'll be concerned with the three circled values in the sysfs path, and also the version number above it. We'll come back to this output later for the name and input device path:

Convert the endianness of the three syspath IDs, and append the version. (Swap the first two characters with the last two and add four 0s). So for my gamepad:

• 0003 = 03000000
• 081f = 1f080000
• e401 = 01e40000
• 0110 = 10010000

and the end result: 030000001f08000001e4000010010000

I'm not sure if case matters here, but I went with all lowercase since I know it works.

---

I tried different names and SDL doesn't seem to care what you call the gamepad, but I went with the weirdo name I was provided, extra spaces and all:

---

Finally, let's get our mappings. Install jstest if you don't have it:

$ sudo apt update $ sudo apt install jstest

And also refer to the Handler section in our original output to know which input device to pass to jstest.

For me, it's js0, so I'll pass /dev/input/js0 to jstest:

$ jstest --normal /dev/input/js0

The output looks like this, and is interactive. Each switch should flip when you push a button on the gamepad. Be sure to note the corresponding axis or button numbers.

Now that we know what button is what, we just need to add them to our config string. SDL assumes an Xbox-like gamepad layout. Together with the standard Pico-8 layout it will be mapped like this, but with the button numbers you collected from jstest:

• a: ❎
• b: 🅾️
• x: 🅾️
• y: ❎
• start: pause/options menu
• dpup: ⬆️
• dpdown: ⬇️
• dpleft: ⬅
• dpright: ➡

---

Finally, put it all together! Here's what mine looks like, with funky spaces in the name and all buttons mapped: (note how the axes are expressed as -a1, +a1, -a0, +a0)

030000001f08000001e4000010010000,USB gamepad ,a:b2,b:b1,x:b3,y:b0,back:b8,start:b9,leftshoulder:b4,rightshoulder:b5,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0,lefttrigger:b6,righttrigger:b7,

Drop that into your sdl_controllers.txt, and it should map successfully. Fire up Pico-8 in a separate terminal window, and then check the log. You should see something like this towards the end:

If it was unsuccessful, it will look like this:

Good luck! 😃

Ran into this on MacOS Mojave. If you put a '.' in the filename when you export binaries, the unzipped app will launch just fine, but the zipped one won't.

I made a quick video:
https://youtu.be/NZHUZV4gLGU

 

mozonogozi

by ridgekuhn

Cart #mozonogozi-0 | 2020-07-14 | Code ▽ | Embed ▽ | No License

16

Hi, friends!

I've just finished my first ever video game!

I just want to thank this entire community for existing and being so helpful and friendly. I discovered Pico-8 in April; at the peak of COVID-19 hitting my hometown, and in the depths of a massive depression brought on by isolation/lack of work/personal losses from the pandemic. It's been a lifelong dream to make a game, but I never thought I'd ever actually accomplish it, and making a little progress on this project each day feels like one of the few things that has really kept me going. So, thank you all!!!

Special thanks to @Liquidream for leading me here in the first place, and being kind enough to do some playtesting and providing lots of helpful feedback along the way. Also thanks to @MBoffin for their zine, which got me started, and for feedback in the forums when I was trying to figure out managing game state.

Also, I have a resprite with (better?) music up on itch.io:
https://ridgek.itch.io/killer-kegs

I think I'm here to stay! On to the next one!

Hi friends, does anyone have a hacky JS workaround for preventing pinch/zoom on itch.io in iOS? I just uploaded my first Pico-8 game there and it's more or less unplayable. (I don't own an Android device, so I don't know if this is also a problem on there.) Looks like the exported JS from 0.2.1b already employs a few workarounds to prevent touch gestures, but this doesn't do much when it's in an iFrame because you can still pinch and zoom on the parent document.

Hello, new friends! I discovered Pico-8 a few weeks ago and this is my first post in here!

I'm currently trying to create a framework to manage game state for some future creation, and am hoping to get some feedback on what I've put together so far. Any insight would be greatly appreciated; I'm a web developer and consider myself reasonably proficient in PHP/JS, but this is my first Pico-8 project/first video game/first time working with Lua/first time writing my own FSM ever, so I'm feeling very unsure of myself! I'm looking over it and asking myself questions like; have I over-complicated this? Does the game/level hierarchy make sense? Is it DRY enough? Is there a better way!? etc, etc!

The state hierarchy of the cart looks like this:

App
|_Title Menu State
|_Config Menu State
|_Game State
  |_Init
  |_Running
  | |_Level State
  |   |_Start
  |   |_Running
  |   |_End
  |_Over

So, the first state the app is in is the Title Menu state, where you can either start the game or enter the Config Menu (for picking levels to start on or some other arbitrary config). From either of those, you can enter the Game State. Once we're in the Game State, it initializes, then begins running through the Level States (which just run 3s timers for demo purposes). Each level gets a Start state for saying 'ready, go' or whatever, a Running state for actually playing the game, and an End state for congratulating the player for completing the level or something.

One thing I did which I noticed is different from some of the tutorials I've seen is that I'm calling _init() rather than game_init() or level_init() when I make any state change. I realize this isn't super efficient, but I think it makes sense because any time I make a state change at any level, the program has to flow through the entire FSM hierarchy, which might be easier to debug in the future maybe? Does that make sense, or am I just wasting CPU cycles?

I'm looking forward to learning more from everyone, and hopefully making something actually enjoyable some day! Thanks!!! :)

Cart is attached, and also on GitHub

dojotizoko

by ridgekuhn

Cart #dojotizoko-0 | 2020-05-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA