Index
> Linux > Fastest text graphics for linux? |
| Author |
|
|
rCX 30 Sep 2009, 02:22
I have a similar question. How would I print a character with a specific row, column, foreground and background color in a Linux terminal?
|
|||
30 Sep 2009, 02:22 |
|
|
revolution 30 Sep 2009, 03:32
Perhaps this topic would receive a better response in the Linux forum. You may want to ask a mod to move it for you.
|
|||
|
30 Sep 2009, 03:32 |
|
|
fpga 30 Sep 2009, 06:51
Will do!
I only posted here in case there was some well known os-independent asm trick to access the graphics card directly. I'm afraid I'm very weak in asm and graphics. |
|||
|
30 Sep 2009, 06:51 |
|
|
revolution 30 Sep 2009, 08:26
fpga wrote: ... some well known os-independent asm trick to access the graphics card directly. However, my guess, is that in Linux the console screens emulate some some type of terminal escape codes. So depending upon which terminal they emulate (possibly xterm) then the appropriate escape codes would allow you to set colours and things. However2 as to your question about the fastest way, then this is also not the solution. As is always the case with computers the fastest way to access hardware is directly, that means with your own driver. But be sure the you really need the fastest way because it is likely to be a lot of work to gain just a little bit of speed advantage over the normal methods. |
|||
|
30 Sep 2009, 08:26 |
|
|
Feryno 30 Sep 2009, 08:49
http://board.flatassembler.net/topic.php?p=78367#78367
check the example with the name window from asmutils http://asm.sourceforge.net/asmutils.html |
|||
|
30 Sep 2009, 08:49 |
|
|
vid 30 Sep 2009, 15:42
wondering... why do you need such extreme speed?
In theory, kernel code with direct access to video HW (for flipping buffers) and video RAM should be fastest, but completely unportable to different machine / OS, probably quite undocummented, and very impractical  |
|||
|
30 Sep 2009, 15:42 |
|
|
fpga 30 Sep 2009, 17:13
Thankyou both for your reponses!
Because of my poor asm it's good to hear that that the gain from writing my own driver would be marginal and that most other asm options are inappropriate. That's actually very helpful. As you know I'm already looking at the escape code method. The dev/vcsa method (window.asm) looks promising cos they said it's DOS-like. I saw a previous post of Feryno's and tried windows.asm but couldn't compile it. I managed to do it this time but nothing got displayed. Compiling seems a bit hit and miss even with the correct version of nasm. I am intrigued by this method though. I've got something working in Linux/ncurses but my previous work using Powerbasic/Windows API seemed faster. Does that sound right? I need to do a like-for-like test at some point cos I did add to the non-graphics functionality and went oop. I looked at Directfb (attracted by h/ware acceleration) but had a 'mare trying to get it working. I also tried an Svgalib eg. It compiled but also did nothing. I'm wondering about Allegro i.e. is it fast?? If anyone has seen any more dev/vcsa demos please let me know. I'm working towards this sort of functionality that I can call from c++ Code: Write_chars(char[], x[], y[], fg[], bg[]){ for(int i=0;i<no of items in char[];i++ ){ Print_ch(char[i],x[i],y[i],fg[i],bg[i]) } } whilst accepting non-blocking keyboard entry (I'm doing this with ncurses at present) together with a function to clear the screen. |
|||
|
30 Sep 2009, 17:13 |
|
|
fpga 30 Sep 2009, 18:51
Hi Vid thanks for your comments and interest.
This is for logistical simulation (discrete event) which I've been away from for many years. Whilst you try to abstract as much as possible real world models are infinitely more complex than those used to sell such technology and even the highest end pc's were never quick enough. My models are typically "beasts" requiring several hours to produce results informing as to what the next experimental change should be. I use the numerical output but as an experienced practitoner I can also tell much from the visual buildup of situations afforded by graphics. Unfortunately such insight slows things down significantly. With graphics off memory bandwidth seems to be key cos you're in a big loop unceasingly moving lots of pointers around memory as directed by a priority queue scheduled by a library of inverse cumulative distribution functions driven by a random number generator. The thing runs like a chainsaw sometimes for days. You can have many thousands of parts moving around all driven by individual orders and inter-dependent rules i.e. not the same as games that lend themselves to parallelization. If it was a word processor I'd leave it but in this case the faster the graphics and therefore speed of the model the easier it is to spot causes and trends and get the job done. Hope this explains things. As an aside Is there a 64-bit DOS-like OS with support for a fast executing language + file system fpu support for a library of inverse cumulative distribution functions (I don't want to write either) fast high res text graphics high memory bandwidth BTW I don't know how to write kernel code but have put it on my list of things to look at. Thanks once again |
|||
|
30 Sep 2009, 18:51 |
|
|
fpga 30 Sep 2009, 19:17
Between escape codes under Xterm and dev/vcsa this man seems to think that for his product mcl (whatever that is) dev/vcsa is faster. This tends to support the comment that it is DOS-like.
from http://www.andreasen.org/mcl/README.html " The fastest mode of operation is under a Virtual Console found under Linux. However, since version 0.51.00, mcl supports normal TTY output to any VT100/ANSI comptaible console - for example an Xterm " Last edited by fpga on 01 Oct 2009, 07:13; edited 2 times in total |
|||
|
30 Sep 2009, 19:17 |
|
|
r22 30 Sep 2009, 20:34
@fpga
You may want to consider how you structure your data as well. Referring to your c++ snippet, having 5 separate arrays (c, x, y, f, b) may cause a considerable slow down in your ASM optimized code. Using one array for your data and passing the pointer to the array to your print_ch function would be the best option. i.e: Code: struct Plot c dw ? ;;character x dw ? ;;x pos y dw ? ;;y pos color dw ? ;;color 2 bytes fg|bg ends Array rq WINDOW_WIDTH * WINDOW_HEIGHT ;; rq = 8 bytes (the size of Plot) Having your data closer together will make retrieving it faster per iteration. Separate arrays mean separate blocks of memory, so every iteration you would be retrieving code from 5 different memory blocks causing cache misses and random access vs sequential access slow downs. |
|||
|
30 Sep 2009, 20:34 |
|
|
fpga 01 Oct 2009, 07:09
That looks like very good advice. I've never handled arrays, or anything else, in asm really. A while back I looked at the standalone Forth's without the time to learn asm. Hopefully I've got a bit more time now.
Thanks |
|||
|
01 Oct 2009, 07:09 |
|
< Last Thread | Next Thread > |
Forum Rules:
|