Who's Online |
79 user(s) are online ( 47 user(s) are browsing Forums)
Members: 1
Guests: 78
DrProton,
more...
|
|
|
|
|
Re: OWB3.23 praise and question thread
|
Posted on: 2010/1/17 16:12
#481
|
Quite a regular 
|
@MaXXiMuZZ
Font aliasing is a system-wide feature: you should change the font settings for that (see the Font preferences program).
|
|
|
|
|
|
Re: OS4.1 Update 1 problems & solutions
|
Posted on: 2010/1/17 15:56
#482
|
Quite a regular
|
@salass00 Quote: Probably it's the same thing that happens when recording on ?A1, the audio driver overrides whatever volume setting is set in Mixer. So it seems. What's strange is that before Update1 I didn't happen, and Mixer and TuneNet don't seem to be directly involved.
|
|
|
|
|
|
Re: OS4.1 Update 1 problems & solutions
|
Posted on: 2010/1/17 15:09
#483
|
Quite a regular
|
@Raziel Quote: How easy could there be a regression/reintroduction of a known bug with all thoser changes?  The problem is not with Mixer (Mixer has not changed with Update1) and maybe it isn't even a bug - to me, it just seems that applications can override Mixer's settings. More information: I've just tested the old version I was using (0.8652 - IIRC if was followed by at least another version which I discarded for some reason I can't remember) and the problem does happen! However, I'm pretty sure I didn't have it before Update1. So, if it isn't Mixer's nor TuneNet's fault, maybe it's something in the audio (AHI?) drivers?
|
|
|
|
|
|
Re: OS4.1 Update 1 problems & solutions
|
Posted on: 2010/1/17 13:36
#484
|
Quite a regular
|
@Raziel & Bean Quote:
I experienced the same, but it's not TuneNet's fault i'm afraid
1) Play an MP3 through TuneNet and adjust the sound to what you find appropriate in Mixer (i.e. -20db)
2) Now play a .wav file through TuneNet and the Mixer prefs will get changed (dunno why), the sound itself will be too loud as if the settings has been changed on-the-fly back to the original settings, although the sliders in Mixer stay the same
3) Play an MP3 again and it will be too loud 
The strange thing is, i need to move the Mixer's slider down or up and the volume level "jumps" down to my volume originally set, you will hear it especially if you set the volume down very low
Seems to be either a problem of the OS4 sound handling or Mixer has a bug yet to determine?
edit: Some more information
from Mixer README:
- When starting audio programs like AmigaAmp, these programs can change the volumes too and this change won't be seen in the Mixer.
Another program is not started while playback of sound files, but maybe the plugins use foreign code that could be checked against?
Of course, i could also be on the completely wrong track
I just did a few tests and I can confirm that it's like you say. But, unlike I said in my previous post, it's the playback PCM volume that is affected, not the master. IIRC, this used to happen in the past, but at some point it got fixed. Now it's back. IMHO no program should be allowed to override the Mixer settings. By the way, personally, I wish that the Mixer and AHI preferences merge sometime.
|
|
|
|
|
|
Re: OS4.1 Update 1 problems & solutions
|
Posted on: 2010/1/17 12:24
#485
|
Quite a regular
|
@bean Quote: TuneNet should work fine with the mixer (in either AHI device or Music Unit mode). Can you give me more info as I can't recreate this here? Sure, but I can't right now - I'll make a few tests and give you a detailed report later today. Anyway, since my original explanation sucks, here's what I noticed yesterday: 1. I run TuneNet; 2. I start playing something and the volume is very pumped up; 3. it's enough to slightly (say, 1 pixel) move the Mixer master volume control to get lower the volume to the right intensity (say, about half). Please keep in mind that the above has still to be verified. I'll let you know ASAP.
|
|
|
|
|
|
Re: OS4.1 Update 1 problems & solutions
|
Posted on: 2010/1/16 18:00
#486
|
Quite a regular
|
Here's the list of the problems on my A1 XE G4: * requesters rendering is broken (screenshots: 1, 2); * DDC fails with my Acer AL1916W (no big issue: I prefer setting parameters manually anyway); * programs run as default tools do not read their tooltypes if APPDIR: is used; * DiskImageGUI freezes the whole system to the point that a hardware reset is necessary (but diskimage.device is OK, as I can mount images without problems with MountDiskImage); * TuneNet does not seem to take into account the Mixer volumes (I have not checked this thoroughly yet); * RAWBInfo seems to have lost the FRAMELESS tooltype. Quick suggestions for the future: * icons scaling in AmiDock (as others said); * single-click to enter directories in requesters (as it once was - I really hoped this update would bring back the old behaviour).
Edited by saimo on 2010/1/16 18:33:21
Edited by saimo on 2010/1/17 16:40:04
Edited by saimo on 2010/1/19 22:12:50
|
|
|
|
|
|
Re: AmigaOS 4.1 benchmark
|
Posted on: 2010/1/16 17:06
#487
|
Quite a regular
|
Tests after installing the AmigaOS 4.1 Update 1 Quote:
******************************************************************************
* ramspeed -b 3
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04
4Gb per pass mode
INTEGER Copy: 164.83 Mb/s
INTEGER Scale: 166.37 Mb/s
INTEGER Add: 167.37 Mb/s
INTEGER Triad: 154.37 Mb/s
---
INTEGER AVERAGE: 163.23 Mb/s
******************************************************************************
* ramspeed -b 6
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04
4Gb per pass mode
FL-POINT Copy: 224.81 Mb/s
FL-POINT Scale: 224.81 Mb/s
FL-POINT Add: 186.86 Mb/s
FL-POINT Triad: 186.75 Mb/s
---
FL-POINT AVERAGE: 205.81 Mb/s
******************************************************************************
* DiskSpeed DRIVE=HD3: ALL LONG
* (SFS partition)
DiskSpeed 4.3, OS4 version
Copyright ? 1989-92 MKSoft Development
Copyright ? 2003-04 Daniel J. Andrea II & St?phane Guillard
------------------------------------------------------------
CPU: 68020 AmigaOS Version: 53.12 Normal Video DMA
Device: HD3: Buffers: 1000
Testing directory manipulation speed.
File Create: 7085 files/sec
File Open: 26615 files/sec
Directory Scan: 224515 files/sec
File Delete: 7444 files/sec
Seek/Read: 125000 seeks/sec
Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 12270080 bytes/sec
Write to file: 26468736 bytes/sec
Read from file: 66065856 bytes/sec
Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 23381504 bytes/sec
Write to file: 240470016 bytes/sec
Read from file: 239370752 bytes/sec
Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 23715840 bytes/sec
Write to file: 156913664 bytes/sec
Read from file: 187850752 bytes/sec
Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 30900224 bytes/sec
Write to file: 39616512 bytes/sec
Read from file: 31358976 bytes/sec
Not much changed. The system seems to be snappier, though, so maybe memory allocation/deallocation has improved. EDIT I gave a spin to SFS2 and JFXS, too. Quote:
******************************************************************************
* DiskSpeed DRIVE=HD3: ALL LONG
* (SFS2 partition)
DiskSpeed 4.3, OS4 version
Copyright ? 1989-92 MKSoft Development
Copyright ? 2003-04 Daniel J. Andrea II & St?phane Guillard
------------------------------------------------------------
CPU: 68020 AmigaOS Version: 53.12 Normal Video DMA
Device: dh0: Buffers: 2000
Testing directory manipulation speed.
File Create: 3545 files/sec
File Open: 27855 files/sec
Directory Scan: 224103 files/sec
File Delete: 2842 files/sec
Seek/Read: 136618 seeks/sec
Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 12184512 bytes/sec
Write to file: 28714364 bytes/sec
Read from file: 71491392 bytes/sec
Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 22918656 bytes/sec
Write to file: 221022720 bytes/sec
Read from file: 239467520 bytes/sec
Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 24588288 bytes/sec
Write to file: 61997056 bytes/sec
Read from file: 189485056 bytes/sec
Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 23363584 bytes/sec
Write to file: 32309248 bytes/sec
Read from file: 23035904 bytes/sec
******************************************************************************
* DiskSpeed DRIVE=HD3: ALL LONG
* (JXFS partition)
DiskSpeed 4.3, OS4 version
Copyright ? 1989-92 MKSoft Development
Copyright ? 2003-04 Daniel J. Andrea II & St?phane Guillard
------------------------------------------------------------
CPU: 68020 AmigaOS Version: 53.12 Normal Video DMA
Device: dh0: Buffers: 2000
Testing directory manipulation speed.
File Create: 6918 files/sec
File Open: 26271 files/sec
Directory Scan: 176805 files/sec
File Delete: 9801 files/sec
Seek/Read: 106072 seeks/sec
Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 12659776 bytes/sec
Write to file: 23230454 bytes/sec
Read from file: 55267968 bytes/sec
Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 24103424 bytes/sec
Write to file: 191327744 bytes/sec
Read from file: 227547648 bytes/sec
Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 23953408 bytes/sec
Write to file: 391204864 bytes/sec
Read from file: 168779776 bytes/sec
Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 23789568 bytes/sec
Write to file: 28934144 bytes/sec
Read from file: 19136512 bytes/sec
Edited by saimo on 2010/1/22 18:18:51
|
|
|
|
|
|
Re: BOH
|
Posted on: 2010/1/16 17:03
#488
|
Quite a regular
|
@328gts pheeew... 
|
|
|
|
|
|
Re: BOH
|
Posted on: 2010/1/16 16:25
#489
|
Quite a regular
|
@328gts Quote: my logitech game pad is'nt working in BOH after I installed 'the update" .....Simone please tell me this is a quick fix ... I'm afraid I can't help: BOH doesn't access any OS component directly. Probably libSDL has problems with the new AmigaInput... or, hopefully, you just need to reconfigure AmigaInput. There will be another update in few days, but I won't fix your problem.
|
|
|
|
|
|
Re: Demo Zelda Mystery of Solarus DX
|
Posted on: 2009/12/21 9:19
#490
|
Quite a regular
|
@Mrodfr Quote: BTW, with more and more SDL ports available, this 100% CPU on SDL program ports used could be easily removed with a great a detailed explanation for how resolving this problem IMHO. There is not a specific problem: it's just a matter of understanding what SDL does and how to use it. Quote: EDIT: for the tracker, It's verry strange because work fine and greatly on the SAM here. just see the CPU gauge grow at 100% just after use the play button for a 4 channel module That's just too much, and the problem must lie in the tracker, not SDL. In fact, have a look at this picture: it shows MilkyTracker (which is based on SDL) playing a 4 channel module and updating the window contents (which takes most of the toll) and, as you can see, the CPU usage is far from 100% (for comparison, playing the same module with TuneNet takes about ~3% of CPU power). EDIT: forgot to say: my machine is an A1 XE with a G4 @ 1 GHz, but that's not what justifies such a big difference in numbers.
|
|
|
|
|
|
Re: Demo Zelda Mystery of Solarus DX
|
Posted on: 2009/12/20 13:27
#491
|
Quite a regular
|
@Mrodfr Quote: It really looks like we're not dealing with a bug, but with just "normal" calculations load. I could not try the tracker as it crashed immediately as I launched it, but still I think it's safe enough to say that the problem with the tracker lies simply in the fact that mixing multiple audio channels with all kind of effects, enveloping, etc. at high quality requires a lot of calculations. In other words, it's pretty expectable that playing that kind of music takes a lot of CPU power. More or less the same goes for Zelda (it doesn't use tracker modules, but still requires music synthetizing and mixing). As a counterexample, I have measured the CPU load due to music in BOH's menu: well, the result is that playing a 16-bit stereo OGG music file at 44100 Hz (and, on top of that, there's also a separate stero channel opened, although I don't know whether SDL_mixer voids mixing it altogether when no sample is being used) requires just 2-3% of the CPU power. Apart from the audio part, also the graphics part should be considered - and that's a major factor in SDL's performance. It should be checked how much of the graphics is handled by the CPU/hardware, on the amount of graphics moved from system to video memory and so on. In a nutshell, I just want to say that probably it's not correct to say that SDL is buggy - we could argue whether it's optimized and whether the programs that use it do it properly, but that's a different story. Maybe ports suffer a lot from CPU overloading because ordinary PCs are normally more powerful than our Amigas, therefore programmers tend to use (or maybe waste) lots of resources (f.ex. allocating many audio channels) and use CPU-eating parameters (f.ex. very small mixing buffers, which cause lots of interrupts).
|
|
|
|
|
|
Re: Demo Zelda Mystery of Solarus DX
|
Posted on: 2009/12/19 9:37
#492
|
Quite a regular
|
@Lio Quote: the 100% cpu load is a known bug from SDL, it occurs a lot in SDL ports and is a bad indicator of cpu load... I have used and use SDL a lot and I have never encountered this bug, so please let me get it straight: do you mean that the 100% usage of the CPU itself is the bug (in which can it isn't a bug, but just heavy/unoptimized usage of resources) or that indeed there is some part of SDL which doesn't act as it should, thus causing the overloading of the CPU? @HunoPPC I haven't had the time to test the game yet, so I only had a look at the screenshots: the graphics seem to be taken from SNES' Zelda, is that right (just asking, no bashing intended)? Best luck with this project! EDIT: checked it out. Nice I'm not sure I like the dynamic controls, but it's easy to get used to them and maybe they are indeed useful in certain situations. As for the CPU usage: music stutters a bit, which suggests that maybe the mixing buffers are a bit too small. Increasing them will certainly help with CPU usage (if the game uses SDL_mixer, then it's sufficient to pass a bigger size to Mix_OpenAudio() - BTW, if that function is used, what's the current value?), although care has to be taken to avoid that sound effects lag behind. Ah! While typing here it occurred to me that maybe the game doesn't use simple WAVs... and, in fact, it uses SPCs: since, I guess, they are used to generate synth music, maybe that's what causes such CPU strain...
Edited by saimo on 2009/12/19 17:35:52
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/12/6 14:53
#493
|
Quite a regular
|
@emeck Nice to hear, thanks for letting me know
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/10/6 15:06
#494
|
Quite a regular
|
@emeck @328gts Quote:
328gts wrote:
@saimo
wish I could write a few but last time I programmed anything was in Pascal back in 89 
Well, creating missions requires no programming skills - just have a look at the developer's manual 
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/10/6 10:49
#495
|
Quite a regular
|
@328gts Quote: I'd be happy with endless missions for BOH And I'd be even happier... if those missions were made by others! As long as I'm the only one to produce missions, i'm the only person on Earth who just can't enjoy the game, because I already know where to go and what to do! Anyway, a brand new mission is going to be included in update6
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/10/5 22:59
#496
|
Quite a regular
|
@emeck Quote: No problem, I was expecting a reply by today maybe, not sunday :) Well, I usually answer as soon as I can, also on sundays: I don't like to keep customers waiting Quote: How was the presentation at the show? Hope you got more people interested. Yes, I got more people involved and sold a few copies (and since the show was organized by collectors, practically everybody asked for an autograph). A very good show (some pictures are starting to circulate and soon videos will be out - but they will be entirely in Italian). Thanks for asking Quote: Just for curiosity, from which of the OSes BOH was released has come the most interest until now? Is there a great difference in tastes of users of those OSes? I don't mean just in sales but also in comments and expectations. Since I don't ask about the platform, I don't have precise figures. However, it can be safely said that the order is Windows > AmigaOS > MacOS > Linux (but keep also in mind that the MacOS and Linux versions came later). Comments are the same regardless of the platform. Quote: That's great. Good luck with those other projects. Thank you
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/10/5 10:52
#497
|
Quite a regular
|
@emeck Quote: At last I've got some extra cash and have ordered BOH. Still I have to wait for the funds to be transfered to my paypal account. Ah, yes, your order is the one I've processed terribly late (  ) because I was presenting BOH at the VIDEO GAMES HISTORY 2K9, a show that was held on the last weekend in Monza, a city very far away from here... Quote: I've been playing it with wine in Debian and I like it very much. This is the kind of words that makes me happy the most Quote: Keep the good work and hope to see more releases from you. update6 will be out soon and will include the AROS version For the current feature list, please have a look here. As for other projects, I have plenty of ideas, but I can't tell whether I'll ever be able to work on them.
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/9/20 15:27
#498
|
Quite a regular
|
@328gts Quote: ahh thanks for the explanation..i'll give it a try You're welcome Quote: btw, my manuals page 9 has the 'how to play' section....I better get the digital updated version from your homepage Ah, yes: the page that explains how to set up the video mode properly has been introduced only recently. BTW: if you installed all the updates or installed the game from the ISO image, you already have an updated version of the manual PDF.
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/9/20 12:50
#499
|
Quite a regular
|
@328gts Quote: oops my bad I'm ruuning it at 800x600 smoothly & very fast Still, that's not optimal. BOH's resolution is 320x240. To cover as much as possible of an 800x600 screen, 2x zooming is required - and still part of the screen remains black, as the used area is only 640x480. Since zooming comes at a cost, that's not a big deal. Luckily, since you're playing on AmigaOS, you have the possibility of running BOH at 1x and, at the same time, get the graphics to cover the whole screen. As said, the detailed explanations are on page 9 of the manual, but here I'll give you specific indications for your case. Both the modes you mentioned (1024x768 and 800x600) are 4:3, which makes me think you have a 4:3 monitor. BOH's ratio happens to be 4:3 as well, and that makes things very easy: all you have to do is adding a 320x240x32 tooltype to your monitor icon, check via the ScreenMode preferences that such mode does work and then select the mode in BOH's preferences. Should the mode not be supported by the system, then you can try with: * 400x300x32: this would allow you to play at 1x, although there would be unused areas identical in physical size to those caused by the 800x600 mode; * 640x480x32: this would require 2x zooming again, but at least there wouldn't be unused areas. I hope this helps.
|
|
|
|
|
|
Re: BOH
|
Posted on: 2009/9/19 10:27
#500
|
Quite a regular
|
@328gts You do know how to make a programmer happy Thanks a lot! BTW: 1024x768 is not an optimal resolution, as it requires zooming, which may cause the game to run less smoothly. Please refer to page 9 of the digital user's manual to learn how to set up the video mode correctly.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
