Log In  

Early version with opening doors but hardly anything else:

Cart #nuzukeheba-0 | 2019-05-06 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
12

Much later version with sliding walls, triggers, and enemy AI being tested:

Cart #sudugpir-0 | 2019-05-06 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
12

Severe performance issues in the latter.

P#64204 2019-05-06 14:23

1

The floor mapping is very fast (well, within pico limits!) - clever trick to iterate over 2 columns at the same time.

P#64212 2019-05-06 19:49

Thank you! most likely something I learned from the PCGPE article on texture mapping back in the day. In any case nothing as elaborate as the tricks @Powersaurus has used in his much faster implementation. Actually I submitted this following a twitter thread on how doors can be generalised in order to implement pushwalls

P#64213 2019-05-06 20:13 ( Edited 2019-05-06 20:23)

@Powersaurus main trick for the floor is to reduce resolution (every 4 pixels iirc).
You can do something similar by reducing horizontal resolution (say render every 2 pixels) but keep vertical resolution.

P#64214 2019-05-06 20:34

Unfortunately this wouldn't work for the game I had planned as it uses pressure plates as triggers to open doors / pushwalls, and they are already fairly difficult to tell apart with the current implementation. Low resolution screen and textures proved quite limiting for a 1st-person puzzle maze.

P#64215 2019-05-06 21:26
1

Tile based move then? quite frankly you will struggle keeping 30fps with what you have on screen without some more compromises :/

P#64217 2019-05-07 06:18

This is a typical case of cart before the bull, I carried on adding functionality without regard for performance and then it became quite difficult to isolate where it was going. A console-like development cycle (vertical slice at 10fps, optimise later) doesn't quite work in PICO-8.

P#64219 2019-05-07 07:09

On the other hand pico game codebase is small enough to go through extensive refactoring without loosing much time.
Having a slow but working game is still a good tactic.

P#64220 2019-05-07 07:28

Unfortunately in this case the codebase has become too large for me to manage on the embedded editor (I was working on this during my commute on a PocketCHIP). I need to find a way to do so on a bigger screen with a device I can still use on a crammed train. I tried running PICO-8 with UserLand on a Android tablet but unfortunately SDL binaries don't work with the X client. If Zep releases an Android cart player I may be able to side-edit the contents. It seems this is landing soon, I just hope it can load locally-stored carts.

P#64233 2019-05-07 20:14
1

hey! I was doing the same (until my pocktchip died!).
I was using a dedicated text editor (Textastic on iphone), automatically synced with pchip via ssh.
Once I was happy with code change, I swapped to vnc to see the results.
All that fully remote by connecting to the pchip wifi hotspot (eg pchip stays in the bagpack).

@Maca see my github for the proper wifi setup: https://github.com/freds72/pocketchip

P#64240 2019-05-08 06:22 ( Edited 2019-05-08 08:37)

Wow! That's a pretty awesome setup, with the additional plus of preventing confused looks from fellow commuters. I must try it and get some further use from my PocketCHIP.

P#64241 2019-05-08 08:23
1

This is really nice.

P#65169 2019-06-13 08:54
1

I'm impressed by the moving doors that will actually block where they should, and the comparative performance with mapped textures and everything.

Maybe someday I'll be able to render a 3-D scene.

P#65186 2019-06-14 01:43
1

@zlg: a raycaster is a great place to start! I'm happy to help explaining the code, @Powersaurus write-ups make for a great reference ( @Powersaurus">https://medium.com/ @Powersaurus) and Fabien Sanglard's Game Engine Black Book is also really useful (http://fabiensanglard.net/gebbwolf3d/index.html).

P#65191 2019-06-14 09:37 ( Edited 2019-06-14 09:39)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 15:08:16 | 0.028s | Q:35