GLBasic forum

Main forum => GLBasic - en => Topic started by: mentalthink on 2012-Mar-19

Title: Very Newbie question about INLINE
Post by: mentalthink on 2012-Mar-19
HI in my future projects I like put INLINE commands... I think after all this time I not use, and yet it´s the time  :-[

Only a question, I think it´s truly but only for sure...

Making mathematics calculus INLINE it´s more faster than GLBasic... or I need to make the code in a real .Cpp Source and after implement in GLBasic, or it´s ecaxtly the same

Thanks in advance...
Title: Re: Very Newbie question about INLINE
Post by: MrTAToad on 2012-Mar-19
Technically it could be faster inline as you wouldn't have to deal with DGNat classes.  However, whether the actual speed increase is noticable is another matter :)
Title: Re: Very Newbie question about INLINE
Post by: mentalthink on 2012-Mar-19
Thanks...
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-20
Technically it could be faster inline as you wouldn't have to deal with DGNat classes.  However, whether the actual speed increase is noticable is another matter :)
Hello again, MrTAToad.

Correct me if I'm wrong, but since GLBasic isn't an interpretive compiler, shouldn't it not make any difference? Classes or not, at most shouldn't it only affect the conversion process prior to compiling? After all, it does compile to standalone machine code executables, doesn't it?
Title: Re: Very Newbie question about INLINE
Post by: Kitty Hello on 2012-Mar-20
Absolutely. If you want more speed, get a better processor ;)
GLBasic is all compiled. You "might" be faster with using static arrays over the dynamic GLBasic ones. But in real life situations it won't affect the overall speed significantly. It introduces new, hard to find problems, though.
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-20
Absolutely. If you want more speed, get a better processor ;)
GLBasic is all compiled. You "might" be faster with using static arrays over the dynamic GLBasic ones. But in real life situations it won't affect the overall speed significantly. It introduces new, hard to find problems, though.
A confirmation from the CEO! Thank you for that. I must say that the spectrum of your cross-platform support is amazing, and although it's been a year since I purchased GLBasic, I'm pretty sure it's the ultimate tool for my mobile platform needs.
Title: Re: Very Newbie question about INLINE
Post by: hardyx on 2012-Mar-20
INLINE is used often for manage complex classes or structures taken from C sources, or calling external functions in libraries. Making simple calculus in C is normally the same speed than GLBasic. If you use integers (%) is faster than floating point variables in all languages. This is important for portable devices.
Title: Very Newbie question about INLINE
Post by: Kitty Hello on 2012-Mar-20
On processors with an fpu, floats are no slower than ints.
Title: Re: Very Newbie question about INLINE
Post by: mentalthink on 2012-Mar-20
Ok, a lot of thanks a lot, I thinked C++ it´s always the most faster languaje...   :x :x

Thanks to all replies
Title: Re: Very Newbie question about INLINE
Post by: ampos on 2012-Mar-20
Ok, a lot of thanks a lot, I thinked C++ it´s always the most faster languaje...   :x :x

Thanks to all replies

No, machine code is (Yoda said)
Title: Re: Very Newbie question about INLINE
Post by: mentalthink on 2012-Mar-20
Si ASM es lo más rápido, pero no me quiero imagina programar el iPhone o el Palm Pre en ASM, si el Amstrad ya es bastante follón, hacer que se mueva un caracter no me imagino como se debe hacer en los cacharros estos...

Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-21
Si ASM es lo más rápido, pero no me quiero imagina programar el iPhone o el Palm Pre en ASM, si el Amstrad ya es bastante follón, hacer que se mueva un caracter no me imagino como se debe hacer en los cacharros estos...
¿Qué diablos? You can still do that, if you had ASM compilers for those phones. But ASM is not machine code.
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-21
When did that change?. As far as I recall ASM is basically mnemonics representing the raw hex numbers of the machine code to make it easier for us humans to write. I first programmed machine code in the late 70's by writing programs in asm on paper then manual converting the commands into hex from the cpu code list.

Sure asm provides some extras like labels etc but the end result is to all intents & purposes machine code with a 1 to 1 translation of mnemonic to cpu opcode. The exception to the rule is macros & such but this is not a lesson on asm.

Lee
Title: Re: Very Newbie question about INLINE
Post by: bigsofty on 2012-Mar-21
GLBasic, ironically, is actually a very nice platform for learning C++, a little basic wrapper can hide all the usual C project stuff allowing the user to concentrate on the inline or linked C. You can even use the GLB command set as a cross platform API from with the C, to a certain extent.
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-21
I have always been "On the fence" so to speak regarding C/C++ in that I have never really got around to learning it or had a need for it's power so to speak. I can work out simple parts of code like loops, branches & conditions etc but beyond that I'm lost  :D

It is on my to-do list to learn some more of C/C++ as there are loads of useful code examples on gamedev.net & other sites for things like effects, engines plus lots of other things. I once converted an improved Bresenham's line algorithm from C in Blitz3d once & even though the Blitz code was 6-7x the length of the C equivalent it was still slightly faster than the native Blitz line command which surprised me.

Lee
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-21
When did that change?. As far as I recall ASM is basically mnemonics representing the raw hex numbers of the machine code to make it easier for us humans to write. I first programmed machine code in the late 70's by writing programs in asm on paper then manual converting the commands into hex from the cpu code list.

Sure asm provides some extras like labels etc but the end result is to all intents & purposes machine code with a 1 to 1 translation of mnemonic to cpu opcode. The exception to the rule is macros & such but this is not a lesson on asm.

Lee
Which makes Assembly a truly low-level language, but still a language nonetheless, that requires translation. Just as you had to "convert the commands into hex", the assembler does the same thing. Technically, nothing's changed.
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-21
Machine Code is a language as well, if you have the patience or boredom to memorise the opcodes. Like I said asm is a 1-1 translation of machine code for us mere mortals to understand so your statement of
Quote
But ASM is not machine code
is correct up to a point but the line is so thin that the difference between them is negligible.

If you avoid any specifics from a particular Assembler (asm code from one Assembler does not mean it will be translated by another Assembler correctly) like labels etc then the output will be identical to the same code had you entered it in machine code, albeit the asm version is considerably easier to read  :D

Lee
Title: Re: Very Newbie question about INLINE
Post by: Kitty Hello on 2012-Mar-21
I talked to the guy that wrote "Mission Elevator" on the CPC and he did what you said - write the whole game on paper and then typed in the numbers. How insane is that!?
And how would you debug anything?
Title: Re: Very Newbie question about INLINE
Post by: bigsofty on 2012-Mar-21
On a related note, I used to work beside a guy used to write his games on a notepad, in hex. His name was Colin Swinborn, he wrote a series of games for the ZX Spectrum called Joe Blade. Pure binary code, no assembler, the only thing he used was a hex editor to turn his notes into an actual file. He even did the animated sprites as binary code in another notepad. He tried to explain to me one day how one of his routines worked but it was gibberish, a page of hex, with hand drawn lines for loops and labels next to certain lines... bonkers but admirable.  :S
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-21
I talked to the guy that wrote "Mission Elevator" on the CPC and he did what you said - write the whole game on paper and then typed in the numbers. How insane is that!?
And how would you debug anything?

Lets just say debugging was more of a "Trial & error" process mainly, multiface type cartridges with monitors helped a lot with regards to debugging allowing you to step through code.

I program pic micro controllers in hex without an assembler but with only 36 odd opcodes it's not really that difficult. I still recognise some z80/6502/68000 hex codes but not the full set from my 8/16bit days. I did not get into PC's really until the 166mmx pentiums, assembly was pretty straight forward on 386/486 but with the additions like mmx & now SSE etc I would not really know where to begin  :D

Lee


Also with the 8/16bit computers the hardware was a known quantity, whereas PC's where a minefield of hardware combo's which I seriously could not be arsed with  :blink:
Title: Re: Very Newbie question about INLINE
Post by: Wampus on 2012-Mar-21
On a related note, I used to work beside a guy used to write his games on a notepad, in hex. His name was Colin Swinborn, he wrote a series of games for the ZX Spectrum called Joe Blade. Pure binary code, no assembler, the only thing he used was a hex editor to turn his notes into an actual file. He even did the animated sprites as binary code in another notepad. He tried to explain to me one day how one of his routines worked but it was gibberish, a page of hex, with hand drawn lines for loops and labels next to certain lines... bonkers but admirable.  :S

(http://i904.photobucket.com/albums/ac242/wheeethefibble/webpics/mogmoment.jpg)
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-22
Machine Code is a language as well ... asm is a 1-1 translation of machine code ... the difference between them is negligible.
Yes, but it's the absolute native command set of the respective processors, and the only codes they could understand and execute. Even Assembly mnemonics would be Greek to them; they wouldn't be able to differentiate a+1 from inc ax, until these are translated into their native opcodes. That's not negligible.
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-22
Even Hex for machine code is only used by us as its a lot easier to remember & shorter write down/type than binary, then the joys of machine code being translated to the lowest level of all "microcode" which gladly only the engineers etc that design the cpu's have to deal with.  =D

Technically machine code is the lowest level available to us mere mortals to use but is not the lowest level that exists in a cpu. At the end of the day the cpu only understands 0's & 1's of which I do not know anyone that writes code in pure binary, bet there is someone somewhere though that does  :D

What's the difference between 0x40 & INC AX, answer is nothing.  Both are exactly the same & neither are understood by the cpu without being translated by a higher lvl language into binary (which is all the computer understands natively) & then executed/stored.

So I am going to stand by my "negligible" comment but that is my personal opinion, you have yours & I respect that as well.

Lee
Title: Re: Very Newbie question about INLINE
Post by: quangdx on 2012-Mar-22
On a related note, I used to work beside a guy used to write his games on a notepad, in hex. His name was Colin Swinborn, he wrote a series of games for the ZX Spectrum called Joe Blade. Pure binary code, no assembler, the only thing he used was a hex editor to turn his notes into an actual file. He even did the animated sprites as binary code in another notepad. He tried to explain to me one day how one of his routines worked but it was gibberish, a page of hex, with hand drawn lines for loops and labels next to certain lines... bonkers but admirable.  :S

Swinborn was a master when I was a kid, loved the Joe Blade games,
and now that you tell me he wrote everything in hex, from designs on a notepad,
his status has been raised to coding God.
Title: Re: Very Newbie question about INLINE
Post by: mentalthink on 2012-Mar-22
@bigsofty
Quote
GLBasic, ironically, is actually a very nice platform for learning C++, a little basic wrapper can hide all the usual C project stuff allowing the user to concentrate on the inline or linked C. You can even use the GLB command set as a cross platform API from with the C, to a certain extent.

This it´s really true, before I use GLbasic, I try to learn C++, but nothing works for me... now I think thanks to GLbasic, I can program in diverse lenguajes... the trouble not are the sintaxis, else know how make the things... whit Glbasic it´s for me the better teacher... well at the beggin something are very strange and hard to do it... but pass this stage, how I say, I think I can develop in another lenguajes, only thanks to GLbasic...
 
I :-* it
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-23
Even Hex for machine code is only used by us as its a lot easier to remember & shorter write down/type than binary, then the joys of machine code being translated to the lowest level of all "microcode" which gladly only the engineers etc that design the cpu's have to deal with.  =D

Technically machine code is the lowest level available to us mere mortals to use but is not the lowest level that exists in a cpu. At the end of the day the cpu only understands 0's & 1's of which I do not know anyone that writes code in pure binary, bet there is someone somewhere though that does  :D

What's the difference between 0x40 & INC AX, answer is nothing.  Both are exactly the same & neither are understood by the cpu without being translated by a higher lvl language into binary (which is all the computer understands natively) & then executed/stored.

So I am going to stand by my "negligible" comment but that is my personal opinion, you have yours & I respect that as well.

Lee

First of all, microcode is the very part of the processor that we are trying to program using machine code. If you want to go lower than that, you'd have to manually apply the electrical voltages to the transistors yourself. So, being mere mortals, let's get back to reality.

Machine code is binary, and only binary. The hexadecimal format is not used as a mnemonic code because it's easier to remember, but because the computers we usually work on do not have the ability to display real binary representation in zeroes and ones. Furthermore, these hexadecimal values need no further conversion, because they already represent the binary values in their bits; for example, 0xC has a binary value of 1100, 0xAA has a binary value of 10101010, and 0xAFC has a binary value of 101011111100. That's not a conversion, but the direct binary bit values of the hexadecimal bytes, which is the machine code in zeroes and ones.

Even if you were to input binary code directly, the sequences that you edit on the screen wouldn't be the real binary values. In fact, it would take more effort for an editor to display binary representations on the screen, having to convert them back and forth between displayable sequences of zeroes and ones, and usable/readable values, be they decimal, octal, or even hexadecimal.

And to your question, "What's the difference between 0x40 & INC AX?", the answer is plenty. Firstly, inc ax is an Assembly language instruction that requires compilation before the processor can understand it, while 0x40 is only a hexadecimal value. However, if this hexadecimal value is used in the context of a high level language, it would have to be compiled before the processor can understand it. But, on the other hand, if it is used in the context of a raw hex-editor, then the processor would readily be able to understand its binary bit values without any conversion or compilation.

With all due respect, this is not a matter of opinion, but rather one of fact. Assembly language is not machine code, and since one is readily understandable by the processor, and the other needs to be compiled before it is, clearly makes a big difference. Far from negligible.
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-23
Seriously am not going to bother after this but just to correct a couple of points


I am fully aware also of what the binary value of hex equals so to me your explanation was both pedantic & rude as far as I am concerned.

Lee
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-23
For a moment, I really thought that we were having a healthy discussion.

At no stage did I say that hex is a mnemonic but was used by us humans as easier to remember.

But, that's what mnemonic literally means; easy to remember.

Assembly does not require compilation because the mnemonics directly relate to the machine code instruction so it gets translated. Compilation occurs on high level languages not low

And this is not pedantry? The terms compile, convert, and even translate, are semantically interchangeable without losing its intended meaning; however, if you really want to be a stickler for inconsequentials, then the accurate term would be to assemble.

I also did not state machine code is assembly or vice versa, just the negligible part should was referring to  the fact that they both produce the same end result because of the 1-1 translation.

Not always one-to-one, not before it's assembled, and definitely not negligible.

I could have stated hex editor as well but technically that translates the users input of 0x40 to binary

No, it doesn't. Hex editors handle raw data, and the hexadecimal values are read & written byte for byte; unless you have some revolutionarily new bitstream editor.

I am fully aware also of what the binary value of hex equals so to me your explanation was both pedantic & rude as far as I am concerned.

From your clear lack on the subject, your grasp wasn't apparent. And you still didn't correct any points.
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-23
Your ability to always have the last word on every post you make is uncanny as was expected & which part of contradicting my every comment is classed as a healthy discussion  :D

Also your ability to totally misread some of my comments astounds me as in
I could have stated hex editor as well but technically that translates the users input of 0x40 to binary

No, it doesn't. Hex editors handle raw data, and the hexadecimal values are read & written byte for byte; unless you have some revolutionarily new bitstream editor.


keywords there are translates the users input no mention at all of how hex editors handle raw data. Like you said numerous times a cpu works on binary data so the hex editor (either the program itself, a library it uses or whatever) has to translate the users hex input in binary for storage somewhere like ram or a file seeing as not only cpu's but ram etc are also a sequence of 0's & 1's. In fact the chain is considerably longer but why should I write a huge paragraph to explain something that is encapsulated easily into 1 line.

Still, I am going to take my clear lack of the subject away with me, read more books & articles then arrive back where I started.

Please help you self to ripping this post apart like my others as I am sure you will

Lee
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-23
the hex editor (either the program itself, a library it uses or whatever) has to translate the users hex input in binary for storage somewhere like ram or a file seeing as not only cpu's but ram etc are also a sequence of 0's & 1's. In fact the chain is considerably longer...

No, in fact the chain is short and simple; all file I/O is handled by the operating system. Even Assembly facilitates file handling via simple and direct calls to system interrupt 21h (3Dh, 3Fh, 40h, 3Eh), which read & write values byte for byte; no conversions, no libraries. I'm surprised you didn't know that.

Still, I am going to take my clear lack of the subject away with me, read more books & articles then arrive back where I started.

Hope I didn't misread you.
Title: Re: Very Newbie question about INLINE
Post by: belial on 2012-Mar-23
Ahhhhh! Interupts! My macro assembler years are not the most pleasent years of my life. One of my teachers had a saying: "coding assembler is to die slowly"
Title: Re: Very Newbie question about INLINE
Post by: Ian Price on 2012-Mar-24
I deleted the post. The GLBasic forum can be viewed by anyone - young or old. Your post was unnecessarily crude and added nothing to the conversation.

We have had an awful lot of spam postings recently (moderation and filters do help but they still get through), and as a new registered user with few posts, I decided that removal was in the best interests of the community.
Title: Re: Very Newbie question about INLINE
Post by: coder14 on 2012-Mar-24
I deleted the post. The GLBasic forum can be viewed by anyone - young or old. Your post was unnecessarily crude and added nothing to the conversation.

We have had an awful lot of spam postings recently (moderation and filters do help but they still get through), and as a new registered user with few posts, I decided that removal was in the best interests of the community.

No problem! Sorry about the language... just wanted to lighten the mood. Assembly can really kill you, and these guys seem so heavy. Keep up the good work.

But to be fair mine is not really a new account.
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-24
... just wanted to lighten the mood. Assembly can really kill you, and these guys seem so heavy.

You're right; Assembly can kill you, that's why we do it in BASIC. And don't worry, we're cool. It may look heavy, but it's just ribbing.
Title: Re: Very Newbie question about INLINE
Post by: coder14 on 2012-Mar-24
... just wanted to lighten the mood. Assembly can really kill you, and these guys seem so heavy.

You're right; Assembly can kill you, that's why we do it in BASIC. And don't worry, we're cool. It may look heavy, but it's just ribbing.

Yeah man, chill out. Go Basic!
Title: Re: Very Newbie question about INLINE
Post by: Ian Price on 2012-Mar-24
Quote
Yeah man, chill out. Go Basic!
Indeed. All the way. :)

Assembly isn't that difficult on 8/16bit machines and the bug-hunt is always a good game in itself. Of course nowadays we don't HAVE to use assembly to get a game running smoothly and/or fast. GLB does that all for us, pretty much. =D
Title: Re: Very Newbie question about INLINE
Post by: TI-994A on 2012-Mar-24
Assembly isn't that difficult on 8/16bit machines and the bug-hunt is always a good game in itself. Of course nowadays we don't HAVE to use assembly to get a game running smoothly and/or fast. GLB does that all for us, pretty much. =D

Amen to GLBasic!
Title: Re: Very Newbie question about INLINE
Post by: Minion on 2012-Mar-24
Not strictly related, but with the mention of coding stuff on paper and in hex and whatnot I just this minute stumbled upon this and thought it might be worth sharing ....

http://www.youtube.com/watch?v=-K7M2L2CoQk&feature=related

It starts getting interesting around the 1:15 mark.

The guy narrating sounds typical of any one of us lot on this forum ;)
Title: Re: Very Newbie question about INLINE
Post by: hardyx on 2012-Mar-26
It's curious that you are talking about assembler in a "very newbie question" thread. :whistle:
Title: Re: Very Newbie question about INLINE
Post by: belial on 2012-Mar-27
the newbies are not what they use to be =)
Title: Re: Very Newbie question about INLINE
Post by: MrTAToad on 2012-Mar-27
Anyone remember NMI's (Non-maskable interrupts) ?
Title: Re: Very Newbie question about INLINE
Post by: belial on 2012-Mar-27
Not me, most of my assembler was simple video buffer manipulations and mathematics.
Title: Re: Very Newbie question about INLINE
Post by: bigsofty on 2012-Mar-27
I loved assembly language, the first program I wrote was a z80 routine to write a sprite to the screen, the second was to move it from one side to another. It didn't work, the sprite was always on the opposite side. After half an hour head scratching, I realised that it was actually moving the sprite across the screen so fast, it was doing it within a frame fly-back... the power of it knocked me off my seat.

Ah, NMI's, great for raster bar effects! :D
Title: Re: Very Newbie question about INLINE
Post by: Sixth Sense on 2012-Mar-28
 :offtopic:
My first experience with assembly was with a Meccano set in 1957, although I did eventually become more proficient with Stickle Bricks It’s never really helped with My GLbasic programming skills.  =D
Title: Re: Very Newbie question about INLINE
Post by: fuzzy70 on 2012-Mar-28
:offtopic:
My first experience with assembly was with a Meccano set in 1957, although I did eventually become more proficient with Stickle Bricks It’s never really helped with My GLbasic programming skills.  =D

WOW Stickle Bricks, now that is a blast from the past I had forgotten about  :D

Lee
Title: Re: Very Newbie question about INLINE
Post by: Ian Price on 2012-Mar-28
:offtopic:
My first experience with assembly was with a Meccano set in 1957, although I did eventually become more proficient with Stickle Bricks It’s never really helped with My GLbasic programming skills.  =D

LEGO FTW! =D
Title: Re: Very Newbie question about INLINE
Post by: ampos on 2012-Mar-28
I once knew a guy that programmed a "demo" in the Amiga using the Action Replay machine code editor. I was so amazed... (I used AsemPro this days) I asked "what do you do if you want to insert any instruction in your code?" "-oh, easy, just type 'copy mem,size to mem+2'"  :o

Also I did some programs in asm in Amos... first, I do all the program in Amos, printed it on paper and translated all the instructions into ASM...
Title: Re: Very Newbie question about INLINE
Post by: Gary on 2012-Mar-29
Good old NMIs, used to use them a bit on the C64

To me the terms machine code and assembler are interchangeable, my reason for this is you can take raw hex dumps and convert them back to assembler (ok, minus any labels but it is still readable as assembler). Try doing that with a C or GLBasic compiled code
Title: Re: Very Newbie question about INLINE
Post by: bigsofty on 2012-Mar-29
I never found assembly hard but to debug... hehe, that's another story!  ;/