Omnimaga
Calculator Community => Other Calculators => Topic started by: critor on December 12, 2010, 09:53:27 pm
-
mViewer is my BMP viewer for Ndless 1.7.
(http://i63.servimg.com/u/f63/13/23/13/53/nsmtp10.jpg)
The code is based on the demo b JayTe that was published on TI-Bank for Goplat's emulator allmost a year ago.
It also includes some come from Levak (zoom).
Of course nothing very impressing... you allready have such a tool in another topic.
But if I tell you that:
* you can browse the whole filesystem (you can put the reader and the bitmaps in different folders)
* you can scroll while viewing the image (yes, you're not limited to the screen dimensions any more)
* you can zoom in/out on the image (keys: * / )
* you can set the constrat while viewing the image (keys: + -)
* you can open any BMP file:
- included support for 1/2/4/8/16/24/32 bits images
- included support of RGB/RGBA/RGBAX encoding (yes, 'Alpha' is supported - 'X' is ignored)
- included support for BITFIELD mode (specified RGBAX)
- included support for raw or RLE-compressed data
What do you say ?
-
Very nice! Dropping on calc right now.
Edit: Strike that. No d/l link.
-
No d/l link.
Wait a minute. I'm currently uploading the archive.
-
/me prepares an image
-
Wow! Looks very nice! :)
-
It's online.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014
Please, if you manage to find/generate a BMP file which is not displayed correctly, please send it to me without altering it (converting to GIF/JPEG to host the file online would be totally useless...).
Thank you very much.
-
First one I tried doesn't work.
-
First one I tried doesn't work.
Does the included example work?
(if not, there is some problem)
What did you get?
* bad display?
* error message?
* reboot?
I have generated more than a dozen different BMP formats with Paint and The GIMP.
I had no problem with them.
-
Bad display. I got the sample one to work, though.
I also threw a large resolution one on it to no avail. (Reboot)
-
Bad display. I got the sample one to work, though.
I also threw a large resolution one on it to no avail. (Reboot)
Thank you SirCmpwn for testing so quickly.
I've downloaded your attached file.
The display is bad.
I've tried to open the file with TheGIMP and just saved it again without changing anything.
The file size is exactly the same.
A hexadecimal editor is showing a little difference in the header.
(the image data is identic)
And the GIMP file is displayed properly.
I'm going to check that.
(could have been worse than some bytes in the header)
Did you download the file?
Did you generate it yourself? In this case, what software did you use?
Thank you very much!
-
I went to google and searched for "locat." It was a jpeg, so I used Paint.NET to convert it to a .bmp.
-
I went to google and searched for "locat." It was a jpeg, so I used Paint.NET to convert it to a .bmp.
I've found the difference.
The data size is supposed to be stored at offset 0x22h.
On my GIMP file this is ok.
On your file, the size is set to 0.
But it's not a problem beacause your BMP is not compressed: data size can be calculated easly.
I'm recompiling...
-
Sounds good :) I look forward to seeing the new version.
-
I've attached the new binary.
It opens your image, SirCmpwn.
Very nice in grayscale ;)
Thank you for helping me improving the BitMap support.
What were the size, width and height of your high res file?
-
Awesome Critor! Is it based on Bwang's BMP viewer by the way? I don't think he ever updated his for OS 1.7 so I was curious. Nonetheless this looks like a great program. :)
-
Awesome Critor! Is it based on Bwang's BMP viewer by the way?
No it is not.
(I would first have asked for his permission)
The display code is based on the demo that was published on TI-Bank a year ago.
I've added some scrolling code and double-buffering.
Levak helped me to add zoom in/out code.
And BMP support was started from scratch and is designed to be very generic
Bwang's was only supporting 24-bits if i remember well.
Please go on telling me about your good/bad BMP experiences with the viewer.
This might be the 1st program I'm going to submit to Ticalc.
Thank you all again.
-
Size: 1.54 MB
Dimensions: 1024x768
-
Size: 1.54 MB
Dimensions: 1024x768
Strangely, I've got a working 1.75Mb bitmap.
So size doesn't seem to be a problem.
Could you upload that file too?
When you get a reboot, you should try again immediatly.
If it does reboot again, the problem comes from the image.
If it does not, then it was a bug from mViewer or Ndless.
I got some reboots while using mViewer, but they were quite rare and non reproduceable.
I alose got some rare reboots while not using mViewer... (reboots which could then be Ndless related)
-
I'd like to suggest having it zoom in on the currently scrolled-to spot as well, instead of jumping to the top-left.
Image (PNG format, I converted it to a bmp first with the same software as before):
-
Awesome Critor! Is it based on Bwang's BMP viewer by the way?
No it is not.
(I would first have asked for his permission)
The display code is based on the demo that was published on TI-Bank a year ago.
I've added some scrolling code and double-buffering.
Levak helped me to add zoom in/out code.
And BMP support was started from scratch and is designed to be very generic
Bwang's was only supporting 24-bits if i remember well.
Please go on telling me about your good/bad BMP experiences with the viewer.
This might be the 1st program I'm going to submit to Ticalc.
Thank you all again.
Ah ok. I'll probably try it tomorrow unless I forget. I will install OS 1.7 anyway to try Ndless. I wonder how great will the original Omnimaga logo (2001) look like on my Nspire screen. ;D
-
Wow SirCmpwn... that's a huge picture.
The PNG is allready 1.5Mb large...
The 24-bits uncompressed BMP is going to be... bigger! :p
Maybe a malloc did fail...
(any segmentation fault is triggering a reboot on the Nspire)
I suppose I should test for the return of the malloc.
-
I went for stress-testing, and I got it :)
-
I went for stress-testing, and I got it :)
I've converted your PNG to a 24-bits uncompressed BMP (2.25Mb) using The GIMP.
It works on calc, and it looks very great. My Nspire looks great, thanks to you!
Maybe you had less available RAM than me...
Or maybe there was a difference in the file again.
I'll try to install Paint.net tomorrow.
Thanks again.
-
Sounds good, and you're welcome for the epic pics :)
Can you attach the bmp to a post here, so I can try it, too?
-
Here's the BMP.
It worked on my calc, so it should work on yours... after a reboot in the worst case (RAM cleared).
We should take a memorial photo after cleaning the screen :p
-
Thanks. Also, in your source code, you have browse.c which exposes chooseFile(char*, char*). This returns an int. What is represented by that int?
-
Thanks. Also, in your source code, you have browse.c which exposes chooseFile(char*, char*). This returns an int. What is represented by that int?
It just indicates if the choice was validated (enter key with a file selected) or cancelled (esc key).
It's like a basic "ok/cancel" borwsing dialog box.
-
Ah, I see. Also, given file and dispHex(char), the following should display the first 5 bytes, correct?
file = fopen(path, "rb");
clrScr();
resetConsole();
for (i = 0; i < 5; i++)
{
fread(currentByte, 1, 1, file);
dispHex(currentByte);
}
-
Ah, I see. Also, given file and dispHex(char), the following should display the first 5 bytes, correct?
file = fopen(path, "rb");
clrScr();
resetConsole();
for (i = 0; i < 5; i++)
{
fread(currentByte, 1, 1, file);
dispHex(currentByte);
}
yes, correct
-
That's odd, because it means that all of my files on my Nspire have five zeros to start them.
-
It might be a pointer problem.
fread takes a char* as 1st argument, not a char.
fread(¤tByte, 1, 1, file);
dispHex(currentByte);
-
What do ya know! That worked.
-
Here's a nice photo!
I've cleaned up the screen :p
(http://i63.servimg.com/u/f63/13/23/13/53/mviewe10.jpg)
-
Wow, those photos display quite nicely. Good job! =)
-
Glad you found a use for my pic :)
-
Wow those pictures are incredible! Is there any sort of dithering involved?
-
Wow those pictures are incredible! Is there any sort of dithering involved?
There is certainly "something".
The pictures look much better on the true hardware that on the emulator.
-
really? usually, the emulator shows it better, since it does perfect greyscale whereas the nspire, well, doesn't :P
nice, and I like having a file browser!
-
Updated:
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014
Fixed severall little bugs:
- the text console was loosing 1 character when reaching the bottom of the screen
- the browser scrolling was bad if there were more than 2 pages of files
- RLE compressed bitmaps were not read correctly if the 0x00FF escape command was found
Remaining bug:
- if the image has been scrolled (top-left corner offset is not null), the zoom in/out is "sometimes" not centered properly.
I've mentioned Omnimaga for the tests in the readme.
-
I read on hackspire that the LCD driver supports 8 bit gs. Could this be a possibility for a future version?
-
I read on hackspire that the LCD driver supports 8 bit gs. Could this be a possibility for a future version?
It's not 256-level grayscale, it's 8-bit pixel data. The 8 bits are used to look up color values in a palette.
-
Can we define the palette?
-
Yes. The array is located at 0xC0000200 (full info at http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#C0000000_-_LCD_controller (http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#C0000000_-_LCD_controller))
-
So does this mean that, for example, we could do a perfect fade through 256 shades of gray?
-
I read on hackspire that the LCD driver supports 8 bit gs. Could this be a possibility for a future version?
It's not 256-level grayscale, it's 8-bit pixel data. The 8 bits are used to look up color values in a palette.
-
If we control the palette, then my statement is still valid.
-
No, it isn't. The palette is used to look up color values, of which there are still only 15.
-
Thank you. So what we can do is change the values of particualr nibbles as the LCD would see them, correct? We could make 0xF black, for instance.
-
Right (in 4-bit mode). In 8-bit mode, you can have each of the values 0x00-0xFF correspond to a 15-level grayscale color. This might be useful even if just for the sake of being able to read/write pixels byte-by-byte instead of having to extract nibbles.
-
That could make it more speedy, I guess.
-
That could make it more speedy, I guess.
What do you want to be faster?
My code is allready telling the Nspire to wait! :p
Remember we have 90MHz. ;)
No, it isn't. The palette is used to look up color values, of which there are still only 15.
Ok, the palette may be limited to 15/16 entries.
But... it seems there is a 16bpp mode.
And in this mode, each pixel is supposed to contain directly a 16-bit RGB/BGR color value and not a palette index.
Which would mean we can have 256-level grayscale ? . . . ;)
-
Remember we have 90MHz. ;)
*150MHz
-
The palette contains 16-bit color values, anyway (and is limited to 256 entries). The upper 4 bits of the R portion of the value determines the grayscale level.
-
Excuse the double post, I have some important info here.
critor, you say your code tells the Nspire to wait, but it doesn't do that during actual bitmap display. The code seems to run rather slowly. I'd like to suggest an alternative dispBufIMG routine that uses fixed point and less calculations in the innermost loop (may require tweaking to work, this particular one hasn't been tested):
void dispBufIMG(unsigned char* buf, int xoff, int yoff, char* img, int width, int height, float inc)
{
int dwidth = width<<16, dheight = height<<16;
int data_x = 0, data_y = 0;
unsigned int x, y;
int fixedinc = inc*(1<<16);
int i, j;
if(xoff < 0){
data_x = -xoff;
xoff = 0;
}
if(yoff < 0){
data_y = -yoff;
yoff = 0;
}
char* k;
for(j=data_y, y=yoff; j < dheight && y < SCREEN_HEIGHT; j += fixedinc, y++)
for(i=data_x, x=xoff, k=img+width*(j>>16); i < dwidth && x < SCREEN_WIDTH; i += fixedinc, x++)
setBufPixel(buf, x, y, k[i>>16]);
}
-
Thank you calc84maniac.
I'm going to try.
Edit: got another idea to speed up things even more (although speed doesn't seem to be a problem here).
-
Forget about mViewer and its 16 grayscale levels (4-bits).
The last build of mViewer is now able to display your bitmaps in not less than 31 different grayscale levels! (8-bits)
And guess what? While viewing the image, it as fast as the last public binary.
It was quite hard to take a photo.
(http://i63.servimg.com/u/f63/13/23/13/53/th/superg10.jpg) (http://www.servimg.com/image_preview.php?i=1095&u=13231353)
Note: it looks much better without an APN.
-
What?!? Does that same link on TI-Bank work for the latest version?
-
What?!? Does that same link on TI-Bank work for the latest version?
It's just worked for the 1st time a hour ago.
This special version is not pubic for now.
It needs some more testing/debugging.
The internal buffered data was changed from a 4-bits to 16-bits.
But when I release it, the same link is going to work. And you'going to be informed first! :p
And it should even be faster. the screen refresh code is now only copying the screen content 1 time instead of 2, although it still uses buffering.
Guess what... the Nspire is wonderfull!!!
(why did we have to wait 4 years for that?... silly TI!!!)
-
This viewer is truly amazing! Excellent job, critor! :)
I was wondering, in the future, would it be possible to add support for other image file types?
-
I was wondering, in the future, would it be possible to add support for other image file types?
Yes it would be possible.
We just need the code to decompress those images data to a raw bitmap.
JPEG/PNG/GIF support should be possible.
I think PNG is the easiest format and should be supported first.
JPEG decompression is much harder...
And GIF files can have multiple layers of various dimensions, layers which can cross the canvas border.
-
What?!? Does that same link on TI-Bank work for the latest version?
It's just worked for the 1st time a hour ago.
This special version is not pubic for now.
It needs some more testing/debugging.
The internal buffered data was changed from a 4-bits to 16-bits.
But when I release it, the same link is going to work. And you'going to be informed first! :p
And it should even be faster. the screen refresh code is now only copying the screen content 1 time instead of 2, although it still uses buffering.
Guess what... the Nspire is wonderfull!!!
(why did we have to wait 4 years for that?... silly TI!!!)
Let me guess... storing two images at once in the same buffer in the Red and Blue fields, then flipping the RGB/BGR bit in the control register to make more grayscale levels? I could be completely wrong, though. :P
-
Yes, you're right.
-
If you want to halve the memory requirements, you could set up the 8-bit palette. You could have the upper and lower nibbles determine the R and B values, or you could even have a value from 0 to 31 look up the correct 16-bit color value automatically
-
Forget about mViewer and its 16 grayscale levels (4-bits).
The last build of mViewer is now able to display your bitmaps in not less than 31 different grayscale levels! (8-bits)
And guess what? While viewing the image, it as fast as the last public binary.
It was quite hard to take a photo.
(http://i63.servimg.com/u/f63/13/23/13/53/th/superg10.jpg) (http://www.servimg.com/image_preview.php?i=1095&u=13231353)
Note: it looks much better without an APN.
Isn't that 5bit grayscale? (2^5=32)
I experimented with that a while ago. Are you using the checker pattern, like what is used for 3 lvl grayscale on the 83/84?
And to make sure I have this straight, the LCD driver is physically incapable of displaying any more that 16 shades of gray, right?
-
critor, while sending new images to my calc today to use with this, I came across one that didn't work. :(
This was made in Paint.NET.
-
Just saw this, and once again, epic job, critor O.O
Gonna download this as soon as I have the time.
-
critor, while sending new images to my calc today to use with this, I came across one that didn't work. :(
This was made in Paint.NET.
It works on my calculator.
May be you didn't get the latest binary on TI-Bank.
Anyway, here's my latest build for those who want to test for me.
By default, the image is displayed with 16 grayscale levels.
The 'C' key (like Color or Critor) lets you hot-switch between the 16 and 31 grayscale modes while viewing an image.
The 31 grayscale mode is usefull for images with similar adjacent colors:
This one: http://www.omnimaga.org/index.php?action=dlattach;topic=5712.0;attach=5043;image
Or this one: http://www.omnimaga.org/index.php?action=dlattach;topic=5712.0;attach=4971 (just zoom in on the thumb, and press 'C')
While in 31 grayscale mode, the 'menu' and 'home' keys let you increase/decrease the RGB/BGR invertion delay. (delay is briefly shown on top of the screen)
The quality of the display in 31 grayscale mode seems to be very dependant on that delay.
Please tell me which delay gives you the best display. It might depend upon the image too...
I fear you will all give me different delays... :p
(if there wasn't that problem, I would probably have set the 31 grayscale mode as a default)
-
Woah 31 colors is awesome! I was sure such thing could be possible, because of how good 16 level GS looks like. Do you use the same method as on the TI-83 Plus series, kinda? On the 83+, flashing between black and white to get gray causes some static and flickering to happen. To make the eye think it's flickerless, we simply use a checkered pattern that changes rapidly, creating an illusion of flickerless gray due to the pixels being small. Here's an attachment below
-
I think you can actually check to see if a frame has completed. Wait for bit 2 of 0xC0000020 to become set, then write 4 to 0xC0000028 to clear the bit. Perhaps that will work for good synchronization?
-
It's similar.
I'm flashing between 2 consecutive gray values among the 16 standard ones, in order to get 15 intermediate grey values.
I just hide the 2nde value for each pixel in the blue color bits, and then alternatively swith between RGB and BGR color modes.
So nothing is copied or calculated.
-
Very nice! hooray for 31 colors! ;D
-
I see Critor. Is there a checkered pattern? That said, even with none, I don't think the flickering would be noticeable, though, since the difference between grays isn't too large. Could it be used inside games?
-
Yeah, it would work fine for games as long as the rgb/bgr bit was flipped fast enough. If you used interrupts to sync it with the screen refresh rate, you wouldn't have to bother flipping the bit throughout the code, and the pattern would not slow down even if each frame took a while to render.
-
Here is my latest build of mviewer2.
It's not an alpha version any more: i've promoted it to a beta now! :)
* All graphic functions are now supporting both the standard 4-bits mode (16 grayscale), and the super 16-bits mode (31 grayscale).
* The 31 grayscale mode delay has been set to 40 (40ms very approximatively). This seems to produce the best display on both tested Nspire (a basic and a CAS ClickPad), because the screen must be done refreshing the previous "action".
* No data copy any more to refresh the screen. I'm using 2 identical buffers: onscreen and offscreen. I update the screen when needed just by setting the SCREEN_BASE_ADDR to the start of the offscreen buffer. The 2 buffers roles are switched this way: onscreen is becoming offscreen, and offscreen is becoming onscreen.
* New emergency key to immediatly turn the screen off, if you were about to be caught viewing something forbidden.
* The '"non-centered zoom" bug has been fixed. There is another minor zoom bug.
The 31 grayscale mode doesn't allways give you a better image. It depends upon the image. Images with areas including very similar adjacent grey levels are going to be wonderfull. You'll have the impression of not being able to count the grey levels in those areas any more.
In 31 grayscale mode, if you look carefully you'll guess which are the new 15 levels. Their display is not perfect. This seems to be related to the way the screen refreshes itself.
Here are the keys not mentionned in the readme from the stable link:
- 'C': switch between 16 grayscale mode and 31 grayscale mode
- 'Home' and 'Menu': increase or decrease the 31 grayscale mode delay (if you've got a "bad" display with the default delay - might be removed in the future, depending upon the tests results)
- 'Ctrl': turn the screen on/off
Future tests:
------------
The 31 grayscale mode is obtained by switching the color encoding from RGB to BGR alternatively.
The 2 different gray levels are stored in the R and B bits and then mixed on the screen, producing a new gray level.
There is another way to produce the new grey levels.
It is to have 2 screen buffers containing the different grey levels, and to change the SCREEN_BASE_ADDRESS alternatively between the starts of those buffers.
I wonder if this method would produce better/worse results...
By combining both methods, we could get (in theory) something like 48/64/... grayscale levels. I wonder how it would look like.
64 levels will be hard (propably impossible), because the total refreshing cycle would need something like 120ms. And the human eye is able to detect a 120ms delay.
With a 80ms delay, 48 levels is "limit" but might give something interesting.
Future features:
----------------
* If the tests are good (but don't be too optimistic), more grayscale levels.
* Going back to 8-bit data to spare some more memory.
* Supporting other image files: PNG/JPG/GIF.
-
As an idea, could you add in a loading bar or something like that. I have a few large images that I like to open that take a while and I'd like to have an approximation of the remaining time. (Like a 5 MB pic that takes about two minutes to open) :P
-
Nice, I'll have to try this eventually. :)
By the way what does RGB/BGR? I only think of red-green-blue, but the Nspire is grayscale so I am a bit confused... ???
-
Nice, I'll have to try this eventually. :)
By the way what does RGB/BGR? I only think of red-green-blue, but the Nspire is grayscale so I am a bit confused... ???
The driver takes full 16-bit RGB color values, but only 4 of the bits are used for the Nspire grayscale (it can be selected from the Red or Blue fields)
-
Nice, I'll have to try this eventually. :)
By the way what does RGB/BGR? I only think of red-green-blue, but the Nspire is grayscale so I am a bit confused... ???
The screen does not support colors, but the LCD controller does.
So the LCD controller takes standard colors values in RGB OR BGR format.
-
Oh right, I forgot about that. I see why it uses RGB/BGR, now.
-
Here is mviewer2 beta build 2.
Clearing code (when zooming out) has been optimized in order to clear only a box (although you'll probably won't notice any speed improvement, as I have to wait for the screen...).
I've added the parsing image progress in the top right hand corner, as you've asked for.
Remaining minor bugs:
* strange zoom in some situations
* the contrast delay is causing problems when in 31 gray levels mode
* when going back to the 16 gray levels mode, display mode is not reset to RGB: you may end in BGR mode and so get a slightly darker image, until the next time you press 'C'
You may get a new release before the end of the week.
Todo list:
* develop a "safest" way of waiting for the screen
* test 31 gray levels mode, by changing the screen base pointer, instead of switching between RGB and BGR.
* test modes with more than 31 gray levels
* change internal data from 16-bits to indexed 8-bits
* include PNG support
* include JPEG support
* include GIF support
* iinclude PDF support
-
Nice. By the way, can those pictures be integrated in games?
-
Nice. By the way, can those pictures be integrated in games?
By taking my code and recompiling, yes.
As I'm "waiting" for the screen most of the time, the CPU is available if something has to be done while the image is displayed.
I don't know if it is possible without including my source and compiling: for example, I don't know if it is possible for a Ndless program to launch another Ndless program, and go on once the program has ended.
-
If you mean just displaying an image in an Ndless program, that can easily be done without any of critor's code
-
Ah ok, well I meant a 31 level grayscale one like the ones generated with Critor's program. Thanks for the info.
-
I've managed to compile zlib 1.2.5 library for the TI-Nspire, a light version customized for my needs.
I've removed everything related to compression, file reading, and file writing.
It is only intended to decompress data in buffers.
This is going to be needed for PNG support.
When compiling C code for the TI-Nspire, you have to remove all references to unsupported stdlib functions.
There were such problems in the removed files, but the included files are totally unaltered.
This is totally untested for now, but in case it can be usefull to someone, I've attached it.
Note: as you can guess, the produced binary "dummy.tns" souldn't do anything at all.
-
PNG support sounds cool. Nice update Critor. :)
-
Finally, it's not easy to recompile existing C libraries (lPNG, libJPEG, zlib, sumatraPDF...) for the TI-Nspire.
You've got to remove most #include lines...
You've got to implement some missing functions...
Some libraries are using very OS-dependant functions (memory manager for exemple) which are implemented only for PC/Mac...
And after changing all this, you're getting something that compiles itself.
But it doesn't prove it is going to work...
For exemple, I managed to compile libJPEG and got... a reboot.
I've identified the problem. A similar problem has allready been reported by Mrakoplaz.
A function is stored as a pointer in a struct during initialisation.
And when that function is used (through the pointer) -> reboot... even if the function does nothing.
-
I'm trying to make program ports easier.
I would be interested by the list of missing include files and functions to see how they could be added to Ndless.
May be you could share your patched version once ready (or even if you give up and stop working on it), I could just "diff" it with the orignal version.
-
zlib is already included in the OS by the way, and we have already identified some of its entry points, exporting them as syscalls shouldn't be too hard.
-
On a side note I would recommend to not double-post when there have been less than a few hours between your last reply (if it's the last one) or 1 hour when it's a project update, since on english forums, people tend to not like that ;) (unlike on french ones). In that case it's best to use the edit button. Otherwise I recommend a topic bump, though, else your update will be missed.
-
mViewer has just been updated.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014
The centered zoom in/out bug is now fixed.
New features:
* 32 colors mode (only usefull to improve rendering of shaded images)
* direct scroll of the full screen width/height with the numeric keys (usefull for images containing mostly text)
* emergency power off screen key (in exams? :P... screen won't be turned back on through the On key, but only through Ctrl or Esc keys... which should trick most teachers)
* a more realistic greayscale convertion for color images, based on luminescance
-
Good job! :thumbsup:
-
Would it be possible for a version to be made that works with the touchpad's keypad layout?
Possibly using tab to scroll through the menus or something similar...
-
Yes.
I'm currently working on that.
-
Okay. Didn't want to anger/pressure you, just asking. :D
-
1st public video of mViewer 3.0 "TouchMe Edition"! Enjoy!
(sorry, YouTube did ruin the quality by reencoding the video...)
Could be released today.
-
Touch pad navigation is very nice! It does suck that youtube's re-encoding messed up the video a bit though. :/
-
Touch pad navigation is very nice! It does suck that youtube's re-encoding messed up the video a bit though. :/
Vimeo reencoding (if any) seems to be quite better:
http://vimeo.com/20829444
-
The touchpad action looks nice! I can't compare the video quality, because YouTube blocked the video :P
-
Wow nice, I didn't realize mViewer supported image sizes that big. O.O Great work Critor!
Also I thought that song was by Roxette for some reason. O.o
-
mViewer 3.0 has just been uploaded on TI-Bank.
The archive includes 2 builds:
- one for Ndless 1.7 and compatible (Ndless 1.3/1.4)
- one for Ndless 2.0
Of course, the Ndless 1.7 build doesn't include any TouchPad code. All Ndless 2.0 specific instructions are commented out by macros, and when possible replaced by Ndless 1.7 compatible code.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014
Please test and report any problem.
Thank you very much.
-
JUst tried it and it's pretty great! I like the quality too. :D
I am currently viewing a 3352x2448 BMP file. :P (which happens to be the world map for one of my old games)
-
I don't think providing a Ndless 1.7 build is really useful. Ndless 2.0 is forward compatible and quite stable now.
-
Thanks for that great test, DJ.
How many Mb large is your image?
I don't think providing a Ndless 1.7 build is really useful. Ndless 2.0 is forward compatible and quite stable now.
My Ndless 2.0 build doesn't work with Ndless 1.7.
There are still some very minor bugs with Ndless 2.0.
Your work on this is great, don't misunderstand.
But some of those rare and minor bugs, might become quite annoying during an exam.
I got:
- problems with the screen offset, making it sometimes partially unreadable (rare)
- reboots (rare)
The 1st one is not present with Ndless 1.7 to my knowledge.
So I think it's important for some months to let ClickPad users choose between both Ndless versions.
-
Whoa, those images are huge! And I love the touchpad navigation :D
-
Thanks for that great test, DJ.
How many Mb large is your image?
3.9 MB large. Could it be that I was running out of memory or something? I had a few other large pics on my calc.
-
My Ndless 2.0 build doesn't work with Ndless 1.7.
What happens? Do you know which 2.0-specific feature you are using?
- reboots (rare)
I hope the shift of the screen will be fixed for the final release.
But I don't have any bug reports related to reboots, if you want me to investigate I would need more information.
-
The screen shift issue is actually caused by reads and writes from the screen i/o. A memcpy-ied screen buffer should be used for the reads. Could you check if there is anything like this in your code?
-
The screen shift issue is actually caused by reads and writes from the screen i/o. A memcpy-ied screen buffer should be used for the reads. Could you check if there is anything like this in your code?
mViewer is using its own 16-bits screen buffer.
mViewer's viewer is using 2 buffers. The screen is refreshed by switching the buffers addresses.
But mViewer's browser is reading/writing directly on a single buffer...
And debug messages too...
-
mViewer has been updated to version 3.1.
I've just fixed a little bug: some RLE-compressed BMP weren't readable as the end of the RLE wasn't standard according to the reference documents I've been using.
http://tiplanet.org/forum/viewtopic.php?t=8541
In parallel, I'm still working on mViewer CX:
(http://i43.servimg.com/u/f43/13/23/13/53/nspiro10.jpg)