Yeah i just still haven't looked into macros fully, but really need to know any macros that i could use to define , defines like the below from notcurses.h C header, I just get confused on how the .asm file actually uses the C header files, but if it doesn't when called then as long as i can define these tough syntax's like below, should be able to get it working.

(SO IF ANYONE CAN PROVIDE A FEW EXAMPLE MACROS THAT I COULD MAYBES LOOK AT JUST SOME OF THESE C SYNTAX ARE MULTI COMPLEX LINES, WOULD REALLY APPRECIATE ANY EXAMPLES, OR ANYTHING SIMILAR IN C OF THE SAME FORMAT TYPE , CHEERS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define NCCELL_TRIVIAL_INITIALIZER \
{ .gcluster = '\0', .stylemask = 0, .channels = 0, }
#define NCCELL_CHAR_INITIALIZER(c) \
{ .gcluster = (c), .stylemask = 0, .channels = 0, }
#define NCCELL_INITIALIZER(c, s, chan) \
{ .gcluster = (c), .stylemask = (s), .channels = (chan), }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define NCCHANNEL_INITIALIZER(r, g, b) \
(((uint32_t)r << 16u) + ((uint32_t)g << 8u) + (b) + NC_BGDEFAULT_MASK)

#define NCCHANNELS_INITIALIZER(fr, fg, fb, br, bg, bb) \
((NCCHANNEL_INITIALIZER(fr, fg, fb) << 32ull) + \
(NCCHANNEL_INITIALIZER(br, bg, bb)))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define NCPREFIXSTRLEN (NCPREFIXCOLUMNS + 1)
#define NCIPREFIXSTRLEN (NCIPREFIXCOLUMNS + 1)
#define NCBPREFIXSTRLEN (NCBPREFIXCOLUMNS + 1)
#define NCMETRICFWIDTH(x, cols) ((int)(strlen(x) - ncstrwidth(x) + (cols)))
#define NCPREFIXFMT(x) NCMETRICFWIDTH((x), NCPREFIXCOLUMNS), (x)
#define NCIPREFIXFMT(x) NCMETRIXFWIDTH((x), NCIPREFIXCOLUMNS), (x)
#define NCBPREFIXFMT(x) NCMETRICFWIDTH((x), NCBPREFIXCOLUMNS), (x)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define NCPLANE_OPTION_VSCROLL 0x0020ull
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(I BELIEVE THE *L* STANDS FOR WIDE CHARACTER, BUT NEED SYMBOLS LIKE BELOW)

#define NCBOXDOUBLEW L"╔╗╚╝═║"
#define NCASTERISKS8 L"🞻🞼✳🞽🞾🞿"
#define NCANGLESTR L"🭒🭓🭔🭕🭖🭧🭢🭣🭤🭥🭦"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(AND LASTLY THIS IS 1, I REALLY NEED TO DEFINE)

#define NCKEY_LSHIFT preterunicode(171)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just for anyone that might read, im just looking at macros, can anyone just confirm, do the C header files syntax like ( [ { . -equal the same as- FASM macro ( [ { . , Like do they do the same thing, Just differant syntax and differant languages sometimes do other stuff, And also do things like double quotes and quotes inside quotes work the same and as well the \ extended type syntax, Just if im gonna try macros i need to know the syntax match lol

Just reading on some forum there saying:

This code is not converted to assembly because it is a function-like macro:

#define MAX(x,y) (x>y ? x : y)

?? So how am i meant to define these header equivalents in FASM, That means things like above.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define NCCHANNEL_INITIALIZER(r, g, b) \
(((uint32_t)r << 16u) + ((uint32_t)g << 8u) + (b) + NC_BGDEFAULT_MASK)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Are Function based, so how am i ment to define options like this, Does anybody know about this ?? Thanks

And if FASM doesnt use preprocessor based stuff, these macros have no meaning, says, causes nothing else but a simple textual replacement within your code, Does this mean that all libraries with C headers like the function based macros wont work, somebody must have few answers, ill check back tomorrow. ok

C preprocessor macros are just textual replacements, but can result in compile-time and/or run-time code. This can make conversion rather complex!

Assemble macros do textual replacement, but they don't do code generation. We can look at an example to make this more concrete (using fasmg/fasm2 syntax): If all the arguments are constants then we could simply use: Yet, perhaps the arguments are memory locations or registers to be resolved at runtime? Then we need to approximate some sufficient template (hopefully without writing a compiler in macros ): Assembly macros can get very complex or be avoided entirely by doing the textual replacement and converting the code (as done with C code elsewhere).

Thanks for reply, ive tested few examples and seem to be working already, just 1 last thing do u know how i can define these about the last example i need for making boxes:

#define NCBOXDOUBLEW L"╔╗╚╝═║"

#define NCPLANE_OPTION_VSCROLL 0x0020ull ; (tryed full 16 digits but didnt work still)

which the L just means Wide char but i defoe need these symbols or cannot draw to screen, cheers

Typically, in assembly, we would just put the constant data somewhere and reference the label: ... I'm assuming a lot about constant usage here.

fasm[g|2] uses "du" to output wide characters (UTF-16 word sequences) from the byte string in the code. (Requires "include 'encoding/utf8.inc'", or other encodings of source code supported as well. Take a look at the type implementation - I've learned so much from reading the code of fasm?.)

fixed deleted

Mate just 1 more question i have successfully converted most of my stuff with:

But the below wont work

NCSTYLE_MASK du "0xffffu"

Im defining as this tho without the u:

NCSTYLE_MASK du "0xffff"

Only works with

NCSTYLE_MASK dw "0xffff"

Doesnt the (u) at end mean its

0xffffu is an unsigned hexadecimal number that would typically be defined using DW (Define Word) for a 16-bit value

Do you know why its not working with dw, as i need word ???

Cheers mate

UPDATE,

Says on google:

DW (Define Word): Allocates space for and defines a 16-bit word of data

is also a word so how is dw correct if

So what is the correct 0x hex size for ull unsigned long long

NCOPTION_INHIBIT_SETLOCALE du "0x0001" ; (UINT64 = 0x0000000000000001) + (UINT32 = 0x00000001)

So is the above incorrect for unsigned long long

Confusing a bit

fixed deleted

fixed deleted

OMG , Ive figured it out its OK. I knew it was summet simple

NCALPHA_HIGHCONTRAST dq 0x0000000000000001 <<-- (WORKS)

NCALPHA_HIGHCONTRAST dq "0x0000000000000001" <<-- (FAILS)

Why is the "" brackets only for dw du type words

and

no " " for 0x when used as ints. I shudda knew this and it doesnt work outside of data section when using dq but does when using du/dw. WEIRD.

SORTED - SORTED -SORTED

Only use quotes when you need the string of bytes in the source code - all numerical values should be used directly. (EVAL is kind of a special case because a string of bytes is presented to the assembler for processing.)

Quotes work with the data directives when the string of bytes can be translated into that data type: There are complex conversion things to think about: ... where the source encoding plays a role and more care is needed. For example, working with old extended-ASCII sources - the strings will balloon in size with utf-8 encoding. You can tell I'm just having fun with it.

Generally, you'll want to leave the quotes off where possible.