newline Character

[rustyoz]

was there any particular reason why 0x00A0 was chosen as the newline character instead of 0x000A as according to the ASCII and other standards?

[noxer]

Yes, my fingers typing A before 0. I think is was a typo. I think you have fixed this in you pull request. I will review the code (on tuesday) and then merge the fix.

[rustyoz]

Yes I have included it in one of my commits. Its in the pull request I made but I will try to re organise those commits to make each one for a single problem or feature just to make the commit history a bit neater and merging the code easier

[aponigricon]

0x000A IS A CHARACTER DAMMIT! For special control characters/key characters use anything higher than 0x007F.

[noxer]

0x000A IS THE CHARACTER FOR LINEFEED so why not use it for linefeed?

[aponigricon]

http://0x10cwiki.com/images/f/fc/Font.svg DCPU-16 ASCII IS DIFFERENT FROM TRUE ASCII! Seriously; read up!

[rustyoz]

of course it is different from true ascii, the point is that routines that will be using the newline control character are for text, so we might as well use standard ascii control characters. a direct screen drawing routine might be better which will ignore any control characters

[rustyoz]

and please avoid the use of caps-lock.

[aponigricon]

But what if someone wants to get a bit fancy, and make gui-like containers for text, or drawings? He won't be able to use 0x000A.

PS: I never use caps-lock :P

[rustyoz]

Ah well then we can keep 0x00A0 then since it is easy to remember.

[erisdev]

The right way to draw a gui isn't with text routines; let's stick with ASCII for the sake of compatibility with the outside world, please?

If you want to draw boxes, you should be writing directly to VRAM or (better yet) using drawing routines that will handle that for you. Back in the bad old days, the IBM PC code page 437 character set included several graphical characters in the control characters' slots as well, but that doesn't mean printf("%c%c", 0x0d, 0x0a) was rendered as ◙♪.

[aponigricon]

Sounds fine, but the porblem is that the LEM display, doesn't support direct pixel-by-pixel rendering, it's only graphics mode is text mode, so GUI's are nearly impossible. But the closest you can stick to a GUI from a text graphics mode, is TUI's.

[erisdev]

@VladVP I think you've missed my point somewhat. What I mean is that you shouldn't be calling printf or equivalent to draw boxes onscreen. You can still get those box drawing characters by writing their values directly to VRAM even if the text manipulation routines treat 0x0a as a line feed (as they should).

[rustyoz]

if you want an example of a box drawing routine that doesn't rely on not having 0xA as the line feed symbol look at this https://github.com/bungao/AtlasOS/commit/99f2e1f60e63528ed79c106cace6a99ed42f745e

it draws a nice pretty box of your choice of colour given 2 screen coordinates

[aponigricon]

Hmm... sounds unstable, but if all routines communicate properly it should go...

[rustyoz]

unstable?

[aponigricon]

Well, yeah, if the same hexadecimal numeral character representation, represents two characters, even a printable one, and a control character, some routines may get confused. Fx, if the PUT function tries to print 0x000A, should it print the box drawing character, or make a new line?

[erisdev]

It should make a new line. If you want a ╩ you can put 0x000A into VRAM yourself. It's not really a text character and it shouldn't be treated like one IMO. It's better for everybody if we treat text as standard 7-bit ASCII so we don't have to do extra encoding conversions when data is transported between the DCPU world and the real world.

Functions written specifically for drawing boxes are a better fit for drawing boxes than functions written for outputting text. You more than likely wouldn't want, for instance, the top or bottom outline of your box to wrap around to the next line. Don't try to pretend boxes are a kind of text. C:

[rustyoz]

if you look at the char_put routine all it does it convert the xy coordinates to the correct location in the mapped vram. Also depending on the font that the screen has it could be anything. It is a graphics routine not a text output routine. and makes no distinction between text characters and ascii control characters. that is why the you use text routines for text, and graphics routines for graphics.

[noxer]

ok... since 0x000A is a graphical character and there should be dedicated drawing routines, all functions drawing strings (text_out) should handle 0x000A as a newline. For printing the character on this position the programmer may use char_put. I think the game will have some kind of uplink to the internet so we should stay compatible for now.