As long I’m working very much with images at the moment and the internal tools of AROS seems to have some problems with some special BMPs I wrote a little own Image Viewer for me (a little bit with IrfanView in mind)
At the moment I only opens BMP, ICO, JPG, PNM, PNG maybe later will add some more, I remember I had a very nice image library which compiles out of the box on AROS, could be used then for TIFF/TGA and so on as well (maybe even IFF?)
Until now it is no AROS specific things inside, but maybe would be a nice thing to make an example Datatype loader in pascal language. But atm for my needs this is more than enough to fast browse through my images saved in one debugging session
APict 1.0 for i386-aros
Source again available at GitHub
Magorium send me a link to a pacman clone for freepascal which does not work on AROS currently. I tried to find out whats wrong with it. First it was only the offscreen painting problem which I tried to overcome. But then I noticed how bad this program is, when talking about programming style. The whole drawing is done outside the paint events, which leads to a very bad performance on widgets which does not support drawing outside Paint events (like the MUI interface) because for every draw call the whole widget is called to repaint. The whole process is just paint driven so if you computer is slower it become easier to solve because all items move slower.
I changed it to a paint event driven painting and it work, faster but still very slow.
Of course this is still not a good method, a better approach would be to collect the static pieces into an Bitmap and then draw it at once to the screen in Paint event, and then only paint the Ghosts and the Pac Man to the screen.
An eating of Points/pills and so on would lead to change of the TBitmap. But there only one piece is redrawn. Maybe then it would be come much faster.
But there again one would need an offscreen drawing method, which is possible already, but no chance to plot it to screen. I’m still working on the concept for it but seems I still didn’t find a way. Still fighting with keys and mouse events but at least the pacman clone work now.
Still no interrest on freepascal on AROS, seems my programs didn’t help.
Still fighting with LCL drawing and Event calling, especially the Pen setting and loops in Event makes me headache. There are still some problems inside but I cannot figure out what.
For tests I wrote again a little Testgame, this time a Minesweeper clone.
The Source is again available at GitHub.
FPC Mines on AROS
Same as for the last game, I wrote it in Lazarus Linux and tested in AROS, both looks rather the same. From time to time I must recheck at windows also.
Download for AROS
Today I finished the ArTorr 0.1 Release.
Download:
ArTorr 0.1
News:
- New fancy gui, with pieces and availibility view and more 😉
- Piece-get randomization
- Can be started from shell with torrent file as parameter
- If no parameter given a requester to select will appear
Howto:
- Download the archive
- Unpack at a location you like (in the archive is a Folder with Icon)
- Navigate to the ArTorr Folder
- Start the Program by double click onto the icon
- Select the torrent file
- See how the download goes
- Press quit or close at any time to break the download, the download will be continue when you restart with the same torrent file
- Downloaded files can be found in „Output“ directory in the ArTorr folder
Atm I’m very busy to bring the AROS-fpc to the main branch and also play a little bit with the Amiga Freepascal (I want it for comparison with AROS). So there is only limited time for ArTorr.
But today I bring the new GUI to live already working rather nice. Ok behind the curtain still much to do. I have to think how to prevent, that the gui has to access deep into the Torrent class properties to get all the informations to show. There should be a better solution.
My original plan was to introduce first seeding to ArTorr and then create a GUI, but hmm I have more fun with GUI creating currently. First time I really use the uidesigner for a little bit gui creation (not only testing)
The final ArTorr LAyout looks at the moment like this:
(I filled the pieces view with some random Values, as it will be later, red missing, yellow downloading, green arrived)
My new tracker connection via UDP and HTTP works very nicely. So now all network actions are non blocking. I’m rather satisfied with the whole thing.. it does work without additional Threads. So all the GUI, Network, statistics, sha1 calculation and File writing in a single Thread (the main thread) and it still can reach 3 MB/s and more. Not bad I would say.
Besides this I played little bit the FPGUI Styles and created a very simple (from the Demo style) to make the buttons and so on a little bit modern 😉 looks much better I would say.
So today I made a new Release of ArTorr Version 0.02 new features in short:
- UDP Tracker
- HTTP tracker error handling (working redirect, thanks magorium for this file/report)
- Tracker communication non blocking 🙂
- a little bit nicer interface, but still the same debugging GUI 😉
Download:
ArTorr 0.02
The two words in the headline seems to have no connection… hmm yes its right, I’m just to lazy to write two seperate messages 😛
So the first: Syscall… or better SYSCALL 😉
I backported the SYSCALLs for AROS from the freepascal trunk to my branch. Karoly was so kind to implement (see here) but the rtl there is far from usable. And with the backported we can already begin to transfer the systemlibraries to the new schema, then later not so much work 😛
The porting was more difficult as i guessed, the changes in the code are not so many as you see in the commit, BUT some of this codeparts even does not exists in my branch… introduced in between. Seems also in this part much things happend. But after try to understand the code and compare with PowerPC-MorphOS I found the way to do it.
I tested it with some simple functions from exec.library and it works nicely.
for example:
function RawDoFmtLocal(const formatString: PChar;
const dataStream: Pointer; PutChProc: Pointer;
PutChData: Pointer): Pointer; syscall AOS_ExecBase 87;
I backed a release out of it, just to have it released, my primary target stays the torrent client.
The second point… UDP
I released the ArTorr yesterday and already some bug reports arrived at my desk. On of them was rather simple to understand … in the torrent file was no HTTP tracker, only UDP trackers. I didn’t know such things exist, my files always had at least one HTTP tracker included. The problem is, I have no idea how UDP or the Bittorrent Tracker UDP work. Very helpful is the official text: UDP Tracker Protocol for BitTorrent. But stays the problem how to do a UDP connection. I searched a lot for example codes but the most working with synapse or lNet, both I have not available. But i found this page: Programming with UDP sockets which explains, in C, how UDP connections are working. Its rather easy I would say, even simpler than a TCP connection, and much better for non blocking calls.
So I tried to implement the protocol, its rather straight forward. so tomorrow I will see how it will fit into ArTorr, if this is working I will see how to write myself the HTTP Protocol for the tracker and then make the whole thing non-blocking. 😉 Seems thats my major topic… make things non blocking.
Accomplished some advances for the torrent client… oh people we come closer to a release.
First I implemented the checking of Hash, when a piece is finished. To make sure there was no error in the network or so.
As next point on my list was the state machine for the Bittorrent network, which needs some simplification… so i made a little drawing of the states and transitions, its not very complicated, rather linear and implemented this behaviour. Works fine.
The next point is a big point on my list, a little bit complicated, multiple files. The pieces in the torrent stream are not stopping at a file border or so… just like a stream. On the first sight its not a big deal, if you have the pieces in an order.. but if they arrive randomly you have to calculate the position in the file and in the piece you recieved. For the sha1 calculation I have to keep the piece together, or I would just adjust the blocks inside a piece to get the file border. But I think I got it… downloaded just now a torrent file with 5 files in 3 different folders.. and it worked fine. Still needs a little bit finetuning for the recognition at start, if the file is already there and the sha1 check. Also I have to think about how to check if a file is finished (but not the whole torrent download) that I can rename it already and set free for the user.
I have one more point on my list before i would make a first alpha release…. tracker communication, multiple trackers, tracker reannounce, refresh peerlist, maybe also write an own communication with the tracker (non blocking you remember ;), the TfpHTTPClient is blocking of course)
Good news on the speed front, I transfered the ATorrent program to a native installation (Icaros in qemu) and there its really fast up to >3 MB/s (I have 50MBit so something like 5 MB/s possible), So 3 MB/s (Linux Mint DVD torrent Size: 1.3GB) in a virtual machine not bad, I would say. (Compiled on Linux it reaches also up to 3MB/s). This means my network handling is not that bad.
Seems the tap network for Linux hosted is very slow. there I always only get maximal 200 kb/s even on a local torrent network. (btw. the downloade file is 232.8 MB)
Until now I do not need any Threading. I’m still thinking if it later I will include some Threading possibilities. But my experience with threading at AROS are not so good, often not reproduceable crashes and deadlocks, even for code work perfectly on Linux/Windows.
To achieve this speed level I had to tweek the requests management and peer balancing. It work now much better but I’m still not satisfied. Some examples: If a request timed out (after a minute) I disconnect the peer. I noticed thats not always needed.. sometimes one packages time out but then later the other packages arrive (maybe a problem of the other side). Second: now all peers get the request with same priority, thats not bad but would make more sense if a fast peer is prefered over a slower/limited peer. I think about a kind of credit system for example: all peers start with 100 points. A request to a peer costs 10 Points, if the piece data arrive it earns again 10 points if it arrive at a specific time if it is faster it earns more point if it is slower it earns lower point.
A Timed out package costs 50 points. If the program has a slot free for it chooses the peer with highest points.
hmm maybe such thing would work, but difficult to test and set the right credits for every action.
