🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Additional apiBridge Methods and Parameters

A topic by jozanza created Apr 09, 2017 Views: 110 Replies: 4
Viewing posts 1 to 3
(Edited 1 time)

It would be really cool to get the following methods added to apiBridge

  • DrawCircle - a filled/outlined version
  • DrawRect - a filled/outlined version

The following parameters would be super useful for DrawSprite(), DrawSprites(), and potentially DrawScreenBuffer()

  • rotationAngle - in radians or degrees (not sure what makes more sense)
  • scale - a number by which to scale the sprite(s) or screen buffer

The the following parameter to DrawFont() and DrawFontToBuffer() would reduce a lot of code

  • colorId - I'm not even sure how to print non-white text at this point. ReplaceColorId()?

And here's a general question:

Would it make sense to let these apiBridge methods accept a single table with various properties instead of a crazy huge arguments list? IMHO, it would help a lot for dealing with optional params, trying to remember the order of the params, memoizing params, and adding new options in the future.

I've been thinking a lot about how to handle raw drawing APIs. I love the stuff I'm seeing done in Pico8 these days that use them, but I've been leaning a lot more towards traditional 8-bit consoles that only had sprites. I'm currently wrapping up the new renderer, and I'd like to explore adding those APIs to let you just draw directly into the screen buffer.

As for the fonts, that has been completely re-written. There was a bug in the current version where passing in a color offset does not work. In fact, the screen buffer chip isn't even part of the system any more. I've also added in better support for color shifting as well as the ability to render sprites behind the background layer and defining what part of the screen is cleared and what part of the tilemap renderers to allow you to do HUDs and split screen rendering similar to how the Nes originally worked.

Finally, passing around tables would be expensive for the GC . Right now you can call the APIs and leave off optional values, but you are right, it does require a bit more memorization. This will probably remain. Just before the beta I will scrub the APIs and make sure they are all consistent so that when you call a drawing API, you will know it needs an ID, X, Y position to just work and then specialized optional arguments after that to make them easier to use.

I could definitely get behind a DrawRect(), DrawCircle() and especially DrawLine().

The ability to draw things like targeting rays, or draw primitive things to a buffer once and then repeatedly draw that to the screen buffer would be awesome.

I agree. It's been a struggle to stay true to old hardware but allow some of the cooler stuff I seeing being done with Pico 8. The new API supports pushing raw pixel data to the display as a Sprite (which is capped by the system max sprite limit) or to the tilemap cache which acts like a buffer for rendering the tilemap.

Once I get these new APIs under control I can look into building more helper functions to draw shapes using the existing core drawing APIs.

I have port some of the pico 8 functions and today I rewritten rect and rectfill methods, to be more performance friendly, which allows you to draw lines,rects and filled rects quite quickly. Check my post in this thread: pico-8-to-pixelvision8-tips