#101737 - clone dad - Thu Sep 07, 2006 8:30 pm
I know that theres retawq, but it has to be run from DSlinux, and it doesn't really use the touch screen, and it seems just kind of meh...
Is someone in the process of making another Text based browser for the DS? that would be really cool!
_________________
I don't know anything.
#101742 - Lick - Thu Sep 07, 2006 8:43 pm
I've been thinking about a project like this.
I would make a 'tab' for 'link surfing' and a tab for a 'text surfing'. You can go into link-surfing mode and see only the links and click them. When you arrive at the page you want to view, you switch to text-surfing and see the page-content.
_________________
http://licklick.wordpress.com
#101788 - Nintendo Maniac 64 - Fri Sep 08, 2006 1:14 am
Why not just go farther and use html? DSOrganize can already render htnl quite well so it's a start
#101798 - Darkflame - Fri Sep 08, 2006 3:06 am
yeah, its odd how people act like its an all-or-nothing situation.
Just because you cant do fancy stuff,or make pages look like they do on the web, dosnt mean you cant get basic HTML rendering of text and nice link navigation.
You could even have placeholders for images, which, when clicked on, loads the image seperately. (eg, it goes to the url of the image, and reads it as a jpeg or png).
Personaly my number one thing I wanted was a generic downloader. (something OperaDS cant do).
We kinda have that now, but its not too practical.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#101800 - Mr. Picklesworth - Fri Sep 08, 2006 3:43 am
| Quote: |
| You could even have placeholders for images, which, when clicked on, loads the image seperately. (eg, it goes to the url of the image, and reads it as a jpeg or png). |
To further flesh out that thought:
It would be interesting to have an inter-connected standalone application framework so that the code to display different file types isn't actually stored in the web browser.
Instead, it could consult a file to find a registered (and available) application which can display said file, then boot it with a few command lines.
Of course, that application would be built around the application framework so that it can register itself, it displays the correct downloaded file, and it can return to the right place in the browser.
Some of the power there depends on what kind of tricks can be done with RAM, of course, but it would also open for a great amount of expandability. (Effectively a plug-in system).
I've been pondering a prototype of such a thing on a PC, but I've overburdened myself elsewhere so I can't do it for a while.
If anyone else likes the idea, though... it's not patented ;)
We have a few generic downloaders, actually.
Retawq in DSLinux has a --download command line option, and Links (recently ported, by the way) probably has something similar.
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896
Last edited by Mr. Picklesworth on Fri Sep 08, 2006 6:51 am; edited 1 time in total
#101807 - clone dad - Fri Sep 08, 2006 4:43 am
is anyone actually going to code it? I would love to, but I don't have much free time on my hands to learn CPP...
_________________
I don't know anything.
#101816 - HyperHacker - Fri Sep 08, 2006 6:48 am
Mr. Picklesworth seems to have the right idea. Build your apps with position-independent code so they can just be loaded into any arbitrary memory location and executed. That would be the first step toward simple multitasking.
Alternatively, it's a long shot but if a GBA slot adapter were ever made with onboard RAM that allowed some sort of paging (eg having 32MB of RAM, but able to switch to a mode where only 1MB is mapped at a time), you wouldn't even need position-independent code. You'd just write your apps to reside in whatever area that GBA-slot RAM gets mapped to, and then switch pages when switching tasks; that gives you 1MB for each of up to 32 programs, plus 4MB for the kernel and shared resources.
_________________
I'm a PSP hacker now, but I still <3 DS.
#101834 - DekuTree64 - Fri Sep 08, 2006 9:09 am
Picklesworth's idea sounds pretty simple. Just boot an entirely different program, so it can overwrite the browser's code while it's running. Maybe set up the child application so it only touches certain areas of memory, so when restarting the browser, it can just continue with whatever was in RAM from before. Either that, or write all of RAM out to the storage device before executing the child.
I like the idea of real multitasking better though. I've done a bit of thinking before on how I'd set up a simple OS, optmized for the fact that most programs would do absolutely nothing when inactive.
One program would have full control of the graphics hardware at a time, on the condition that it must be able to relenquish all VRAM at any time to switch to another task.
By default, all programs would be loaded into RAM at once, probably using position independent code. But when switching tasks, the OS would ask the active program wether it will be doing anything while idle or not. If not, then it can be taken out of RAM until it is activated again. Otherwise, it will be kept in RAM and given CPU time similar to if it was still active.
Memory allocation would be managed by the OS, so memory in use by idle programs could be saved off to the storage device if necessary.
Sound could be handled by having programs allocate individual hardware channels. So for example, if you have an Ogg Vorbis player, it can just allocate 2 channels to play its buffers.
Interrupts, and resources like hardware timers would also have to be managed by the OS, to allow the music player and such to run in the background.
Maybe have a certain button combo to switch to the 'desktop', where you can switch between any of the programs currently running, launch new programs, etc. Or just make a 'switch to desktop' OS call, and leave it up to each program to give you a button or whatever for it.
Personally, I think it would be awesome to create a game entirely on the DS. Have a code editor, art program, tracker, file browser, some nice tunes playing, and a couple games to play while you compile, all at once.
Of course, first you'd have to write all those apps, but then again, a lot of them already exist, and wouldn't be hard to 'port' to such an OS.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#101863 - Lick - Fri Sep 08, 2006 2:00 pm
How are you EVER going to get all the required fonts (printable in different colors) and bold and italics and underlines and strikes and different sizes AND tables into the RAM/VRAM? I
I'm veeeery interested in the techniques you'll use.
Saying is easy doing is *really* hard on the DS.
_________________
http://licklick.wordpress.com
#101870 - bjoerngiesler - Fri Sep 08, 2006 3:22 pm
| Lick wrote: |
How are you EVER going to get all the required fonts (printable in different colors) and bold and italics and underlines and strikes and different sizes AND tables into the RAM/VRAM? I
I'm veeeery interested in the techniques you'll use. |
A ISO8859-1 compatible font, stored as an 8bpp bitmap, is about 10KB (10pt) to 20KB (16pt) in size. If you don't need all the glyphs, you can reduce that even more. Say your document uses 20 different font sizes and styles, that would be about half a meg. Just load them from flash cart when you need them.
The fonts aren't the problem. Algorithms are trickier: Tables and frames (esp. making all those web pages look right that use weird table tricks for layouting). Getting CSS right is DAMN tricky, and DAMN computationally intensive.
The biggest problem and rendering speed, and navigating a landscape that is optimized for at least 800x600 pixel windows, in a device that has 256x192 pixels. I don't think I'd want to do that. I have a computer. :-)
From what I read, even Opera DS isn't that great for actual web browsing. Neat toy, but much too slow. I think it's safe to say that no homebrew developer will beat Opera at this game. If we're not better than Opera, we can just buy that.
_________________
DSFTP homepage
#101872 - kevinc - Fri Sep 08, 2006 3:30 pm
| Lick wrote: |
How are you EVER going to get all the required fonts (printable in different colors) and bold and italics and underlines and strikes and different sizes AND tables into the RAM/VRAM? I
I'm veeeery interested in the techniques you'll use.
Saying is easy doing is *really* hard on the DS. |
32 MB RAM in almost every homebrew card? Get yourself a TTF font (about 150k for 2000 glyphs), 4 for normal/bold/italic/bold italic (about 600 k). And then use the rest for the page contents (just mind not doing byte writes). You lose FAT IO, but it's a good start.
// anybody checked the feasibility of a links -g port?
_________________
http://akzeac.blogspot.com
#101873 - bjoerngiesler - Fri Sep 08, 2006 3:34 pm
| kevinc wrote: |
| Get yourself a TTF font (about 150k for 2000 glyphs), 4 for normal/bold/italic/bold italic (about 600 k). |
Render TTF on-the-fly in a device without a FPU? Hmm... that's going to be pretty slow, isn't it? I know you've written a TTF renderer. How fast is that?
_________________
DSFTP homepage
#101875 - kevinc - Fri Sep 08, 2006 3:49 pm
| bjoerngiesler wrote: |
| Render TTF on-the-fly in a device without a FPU? Hmm... that's going to be pretty slow, isn't it? I know you've written a TTF renderer. How fast is that? |
Well, try beup :)
It uses Verdana for arbitrary font sizes.
The TTF renderer uses fixed point for everything (now that I think about it, there are some optimizations left). It's definitely not fast, especially in comparison to bitmaps, but you're not going to need 60 fps. As it's now, it can render a full text screen (arbitrary font/size/color) in about 0.2 secs.
_________________
http://akzeac.blogspot.com
#101876 - Lick - Fri Sep 08, 2006 3:55 pm
Troublesome if you ask me. I agree that buying Opera DS is a better option.
_________________
http://licklick.wordpress.com
#101886 - Darkflame - Fri Sep 08, 2006 5:51 pm
You cant download with it, and its a bit shit for options.
FONT? People are having troubles with the font.
Frecking sake, stop thinking like you have to replicate everything a pc browser does. :p
A single generic font is enough. Italic and Bold are nice. (DSORganiser does this much already, and has enough room left for all its other programs).
| Quote: |
| I think it's safe to say that no homebrew developer will beat Opera at this game. If we're not better than Opera, we can just buy that. |
We can beat it by not trying too:
We dont try to replicate pages.
We have a rather impractical text browser, we have a rather slow profesionaly made port of a pc browser.
I think theres plenty of room in between for something that lets us use a touchscreen interface to browse Html and images and lets us download anything we wish to a card.
I think we have to start thinking what we would actualy use.
I dont care how good a browser is, Im not going to use a DS for general webbrowseing.
But to let me goto someones homebrew site, and download straight from the site, imo would be something i would use often.
| Quote: |
| Picklesworth's idea sounds pretty simple. Just boot an entirely different program, so it can overwrite the browser's code while it's running |
I very much agree.
His idea seems realistic and do-able.
Multi-tasking is nice, but seems optimistic.
Have a html-browser that lets us click on a image placeholder.
It then triggers a seperate program to display the image.....or music....or maybe one day even flash.
The programs could be made and upgraded completely seperately by different people.
The only question in my mind is:
a) Does the browser program download the image data to Ram at a agreeded location, which the secondary program then picks up on.
or
b) It merely pass's the URL of the file, which the second program reads itself.
I am thinking B might be more flexble.
So the "browsers" job is just to display the text in a readable, friendly format with basic tags (IBU, Center, Right Left ect), to have navigationable links, and to trigger secondary programs based on file extension.
Personaly, I dont think we even need frames, and we certainly dont need CSS. It would be nice, but its not going to happen, so why let it hold us back?
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#101900 - kevinc - Fri Sep 08, 2006 7:44 pm
| Darkflame wrote: |
FONT? People are having troubles with the font.
Frecking sake, stop thinking like you have to replicate everything a pc browser does. :p
A single generic font is enough. Italic and Bold are nice. (DSORganiser does this much already, and has enough room left for all its other programs).
|
So you basically want a page viewer with a set of about 10 format tags? That would be... well... trivial. A text reader plugged to an HTML parser does not a browser make. That's why we're discussing fonts :)
You seem keen on this project, why not start a stub and then we can start contributing to it? I'm desperately lacking time right now, and somebody has to start :D
PS: A plugin set would be cool. Each plugin registers itself, which tags it can process, the display region it wants to use, how often it needs processor time, and which priority. Then it get passed events like init, on-start, repaint, timers, on-release, and stuff. And then make everything except the basic stuff get done by plugins. It's not as if we'll be needing real-time.
_________________
http://akzeac.blogspot.com
#101906 - Darkflame - Fri Sep 08, 2006 8:30 pm
| Quote: |
| So you basically want a page viewer with a set of about 10 format tags? That would be... well... trivial. |
...and yet no one has made it yet ;)
And it isnt really trival, not when combined with a plugin system for viewing as many formats as possible.
Not when combined with a nice, easy to use, link navigation system.
Its loads of little projects really.
I think you have summed up my point well, you are thinking about what ""makes a browser"", where as I am just thinking about what would make a nice and usefull DS program.
Rather then aiming high and not getting anywhere, Im just saying we should start low and work our way up ;)
| Quote: |
You seem keen on this project, why not start a stub and then we can start contributing to it? I'm desperately lacking time right now, and somebody has to start :D
|
I am also lacking time, alas.
I did work out a system how I would go about doing it, but I have not enough knowledge in the area to know it was useable.
I was actualy thinking of going though a line at a time writting the information onto a sprite (offscreen).
Then that sprite could be scrolled over one, or even both screens as the user wish's. Seperate sprites could be made for placeholder images, and simply copyed to the main sprite in the correct place and size.
My skills are very limited, about all I made was this little jumping physics demo:
www.darkflame.co.uk/gravity.nds
I have no idea how big a sprite could be. Is it just ram? or is there other limits?
| Quote: |
| PS: A plugin set would be cool. Each plugin registers itself, which tags it can process, the display region it wants to use, how often it needs processor time, and which priority. Then it get passed events like init, on-start, repaint, timers, on-release, and stuff. And then make everything except the basic stuff get done by plugins. It's not as if we'll be needing real-time. |
Yes, also, with plugins, the user could simply disable anything that slows it down too much depending on how much time the user has.
To take an image example, having a plugin completely seperate would let us use almost all the ram for image display.
Even though it would remove the image from the context of the page.
(eg.you see a box, you click on it, it loads the image fullscreen, then you click back to the browser)
Actualy, using this method we could even have plugins that send data back to the main prog.
For instance:
User clicks the image box, image loads fully, when he clicks back though the plugin leaves a shrunk-to-ds-sized raw version in ram that can be picked up by the browser for display in the page in context.
This should make loading pages drasticaly faster, because no image would load unless clicked on.
Its not ideal, but it seems the best of limited ram/resources.
Each plugin gets the most possible ram and cpu to "do its thing" :)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#101912 - HyperHacker - Fri Sep 08, 2006 9:14 pm
DekuTree64, I like some of your ideas, but there is a problem: You can't really use CF or SD cards as swap space. They can only handle a few hundred thousand writes, and using them as swap would kill them pretty fast.
As for interfaces, I figure you'd have one background in bitmap mode for the program "windows" themselves and a taskbar of sorts, another for child "windows", and if that leaves any more I suppose other programs could use them. I put "windows" in quotes because I don't mean like traditional desktop systems where each app has its own box and you can have multiple windows on the screen, drag them, size them etc; at 256x364 (not a typo, keep reading) that probably wouldn't work very well anyway. The idea is each app would have one or two 256x182 windows, one for each screen, taking up the entire screen. The remaining 10 pixels at the top of each screen would display something like a taskbar; on the top screen it would show the time, current program's name (like window titles in other OSes), wifi status etc. The bottom one would display the program's menus, and buttons to swap screens, display a keyboard, switch programs and so on. (Both would have a 'swap screens' button so you could swap back.) Potentially this could be reduced to 8 pixels.
The "child windows" would be things like menus, message boxes, and the keyboard. Maybe an app could display its own too. These things generally wouldn't stay on the screen for long, so using a second layer for them prevents unnecessary redrawing.
I'm not sure how sound would work; the idea of allocating channels to apps that request them seems good. As for CPU distribution, I think the best method would be for the kernel to be mostly ARM7 and let apps use the ARM9 most of the time. Apps could ideally have the kernel do things such as render images and decompress things on the ARM7 while they're doing whatever on ARM9. (IIRC, ARM9 has an exception handler too, so this could help prevent a faulty application crashing the system.) Maybe driver-like programs could be loaded as part of the kernel to offer additional services to all programs, but running on ARM7.
Security doesn't seem like a huge issue, because DS lacks memory protection so in essence every program would be running at kernel level anyway. (Obviously you'd want to make an effort to prevent things like buffer overflows, but don't waste precious CPU power in a futile attempt to prevent programs from doing things like writing other programs' memory. The idea is if you put the program on your memory card and ran it, you authorized it to do whatever. Anything nasty could easily be made into a standalone .nds anyway, so it's kind of a moot point.)
_________________
I'm a PSP hacker now, but I still <3 DS.
#101966 - DekuTree64 - Sat Sep 09, 2006 8:30 am
| HyperHacker wrote: |
| You can't really use CF or SD cards as swap space. They can only handle a few hundred thousand writes, and using them as swap would kill them pretty fast. |
Hmm, hadn't thought of that. I don't know if it would be too much of a problem though, as swaps would only happen when switching programs, and then only if there actually wasn't enough space in main RAM. Still, would be good to have an optional warning of some sort so you can monitor how frequently it's happening.
I like some of your ideas there, especially the title bar/taskbar. Perhaps we should start a seperate thread for OS discussion :)
For the browser, I guess it would be best to have it back up its current state (the html file you are currently viewing, scroll amount, recent pages, etc) and keep it in RAM while running child programs. Probably compressed, to leave as much room as possible.
I would lean more toward having the browser do the downloading of the image file, rather than just passing the URL to the child program. Not so much from a technical standpoint, but because you could keep reading the web page while it downloads.
Image viewers could be made to decompress the entire image in RAM if there is enough space, or otherwise only decompress the portion actually visible on the screen (i.e. chuggity chug when you want to scroll).
I haven't actually used Opera DS, but looking at screenshots, the interface looks pretty nice. Full size view on the top screen, and zoomed out on the bottom to scroll around. But full size spread across both screens would be nice to have as an option, and of course swapping the screens so you can click on links and stuff.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#101981 - Darkflame - Sat Sep 09, 2006 2:15 pm
| Quote: |
| I would lean more toward having the browser do the downloading of the image file, rather than just passing the URL to the child program. Not so much from a technical standpoint, but because you could keep reading the web page while it downloads. |
Yes, theres pro's and con's to each.
I was thinking of passing the URL because
a) Seemed more simple
b) Allowed the plugin to load something a bit at a time, if nesscery. (animated Gif viewing? streaming music? ect)
But your point about reading the page while downloading is a very valid one.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#101982 - Sausage Boy - Sat Sep 09, 2006 2:27 pm
Dammit guys, stop stealing my operating system ideas! I pretty much agree with everything Deku said, most if it I had even thought of myself. My idea for the taskbar would be to use BG1 on the bottom screen (since it's text all the time), and some reserved little area of vram to display a taskbar. The taskbar would be at the bottom, and have a little action button, which would scroll the taskbar layer up, revealing a file browser or something. I've even made a little illustration, enjoy.
It would also be awesome to have a way to save state. That way, .nds files could pretty much be run as "full screen applications", and when you quit them and restart, you would come back where you were. I'm sure everyone can think of numerous situations where a save state would be useful.
_________________
"no offense, but this is the gayest game ever"
#101996 - Mr. Picklesworth - Sat Sep 09, 2006 5:46 pm
| Quote: |
| I would lean more toward having the browser do the downloading of the image file, rather than just passing the URL to the child program. Not so much from a technical standpoint, but because you could keep reading the web page while it downloads. |
Also, with the browser doing the downloading, the image viewer/other plugins would be further simplified and more open to being used by other apps.
Non-standard flags which some specific programs understand could be added to program registries. For example, a program could have the flag StreamingEnabled, which tells the web browser that it doesn't need to (and shouldn't) download the file for the program/plugin/viewer to use.
That way, both options would be available in a relatively clean manner.
I guess downloading to RAM is fine, since many programs just load the whole file into RAM anyway, but an extra option (gark, need some way to pass commands...) to stream from a downloaded file would be nice.
Again, perhaps the viewer program could write a value to registry to specify its preferences. File size tolerance could be noted, too, so the browser could choose whether to dump to RAM or let the program stream from a file if it's capable.
This is a place where RAM extensions come in pretty handy.
Saving program state would be tricky, but more possible with a RAM extension. I think just remembering a few key points and restoring from there could work all right, though.
The reason I think such a system is useful stems from NDSMail, which obviously will need all sorts of built in viewers to be most useful.
/But then why not turn it into a program for viewing local files, too, since it already has the viewers built in?/
The same strange thing occurs with those various programs that are really many programs (DSOrganize, for instance) and could maybe do well being spread out into a few different places.
A solution to all that redundancy is to have a system by which different programs work together more closely.
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896
#102005 - kevinc - Sat Sep 09, 2006 7:33 pm
So, I'd propose this:
First, create a set of basic widgets. Textboxes, menus, fonts, listboxes, et al. Among these the keyboard. They react on their own to keyboard/mouse events, with app hooks for relevant stuff (on change/on click/etc). These may be completely skinnable.
Then create a set of plugins (or applets). These applets do basic, specialized stuff, and can be attached/detached from applications at will. Apps decide where the applet may draw, if anywhere, and when to give them CPU time. Applets must only use the above mentioned widgets, for the sake of code reuse and simplicity.
To start, I'd propose:
- A general image viewer
- An mp3/ogg player
- Wifi config
- File selection
- A file downloader (possibly that can stream)
And there are the applications. They also must use the widgets, and the applets when they need their jobs (code reuse!). They have to be able to run concurrently, and shut down in an orderly way by petition. Each app has complete control on the screen when it's chosen (except for the taskbar space, or maybe the taskbar appears only by a key combo).
For example:
- A file browser: Calls the "image viewer" applet to show thumbnails, the "mp3 player" applet to play music, etc.
- A (simplified) web browser: Displays text and a placeholder for the images. If the user clicks the image space, the browser calls the "downloader" plugin and then the "image viewer" plugin. Or maybe 2 instances of the plugin, one for a zoomed view, other for the complete view.
- A mail client, ftp client, etc.
_________________
http://akzeac.blogspot.com
#102047 - clone dad - Sun Sep 10, 2006 5:13 am
please keep the file under 4mb for us GBAMP users!
_________________
I don't know anything.
#102050 - tepples - Sun Sep 10, 2006 6:14 am
If the plug-ins are loaded as code overlays, then GBAMP users need not worry, as the kernel can load the plug-ins from FAT. MoonShell already does this to an extent.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#102131 - Darkflame - Mon Sep 11, 2006 2:20 am
Sounds quite a smart idea, imo.
Need to break it down into small, achievable tasks.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.