Gen BRC-721 vs ORC-721 for laymen about generative-orc-721 HOT 5 OPEN

Again you are the hero - you started it all! i can't believe it's happening.

The good news - now d.i.y. ordibots (is an ORC-721) collection - now inscribed for real (OG and v2) - ordibots is the OG Gen-BRC-721 collection - so you can compare "identical" collection and see yourself how much simpler and more flexible ORC-721 is compared to Gen BRC-721 NOT to speaking of - trying to "optimize" the bytes (and, thus, saving sats, that is money on inscribes).

Some of the difference are documented right in the readme (did you know?) - see https://github.com/ordbase/generative-orc-721#sample-no-3---diy-ordibots

what questions do you have - feel free (and welcome) to ask & continue here.

from generative-orc-721.

reason it's more flexible

not only - ORC-721 has no required id in mint (avoids duplicate mints with same id) - ids get auto-assigned via bitcon blockchain timestamping ;-) - it's do-it-yourself - in the g spec you can put in nothing or any numbers in range - in Gen-BRC-721 you MUST always use ALL categories in order in the mint AND you must use the attribute id by category AND the attribute key. In ORC-721 - it's all numbers, simply - 0 to .... and no category key or attribute keys required at all (you can inscribe if you want - optional with the spritesheet format in .csv or .json) and on and on. Sometimes less is more :-).

if you are already a graphics person, you don't need to learn about base 64 necessarily to use the protocol. Am I on the right path?

100 % - by keeping the "deploy" inscription (that must be in text) separate from the spritesheet(s) - you can inscribe spritesheet(s) in the "native" format - now in .png for pixel art but .svg also possible or other formats. Simply upload and inscribe - no conversion to .json and base64 BUT yeah sure - you already know - the spritesheet image with tiles of the same size must also be generated (but that's a "classic" in the gaming industy - i am not inventing anything new here - search for tile makers / packers or texture atlas or such - all really different name for spritesheets - in ORC-721 for now spritesheet MUST use always tiles in the same size with NO padding in-between and so on.

from generative-orc-721.

Awesome!

regarding spritesheets - I can make one using any sized images, as long as the generate ruby script is modified so the ImageComposit.read values match the tiles on the spritesheet, and also the size of the new image. Correct?

from generative-orc-721.

I can make one using any sized images,

the tiles (or sprites) all have to be the same size 24x24 or 32x32 not necessarily square e.g. 54x20 or whatever - and, yes, the grid must be a multiple rows / columns of tiles (in deploy you MUST add dim: [24x24] or such to make the "auto-magic" index calculation work ( that is, the tile size or dim(ension) - s is used for slug in deploy - is NOT known to the image / bitmap itself).

PS: if you use the ruby pixelart ImageComposite - always add the keyword params - width: 32, height: 32 or such (default to 24 so sometimes missing in example scripts).

from generative-orc-721.

Thank you. I thought I remembered seeing that somewhere but I couldn't find it. Most compact version of the message is, your 3 bullet points - more compact, more flexible, easier to use. The reason it's more flexible is bc with brc-721 base 64 is the only format that is supported, whereas ORC supports 3 formats. Is that correct?
The more compact is obvious, well played. Also, I think you could emphasize that all of that compactness and flexibility lowers barriers to entry and makes it way more accessible to non coders. For example, if you are already a graphics person, you don't need to learn about base 64 necessarily to use the protocol. Am I on the right path?

from generative-orc-721.