Who's Online |
55 user(s) are online ( 41 user(s) are browsing Forums)
Members: 2
Guests: 53
Georg, Maijestro,
more...
|
|
Headlines |
-
seq.lha - audio/misc
May 29, 2023
-
supermario64_gl4es.lha - game/platform
May 28, 2023
-
supermario64_mgl.lha - game/platform
May 28, 2023
-
amiarcadia.lha - emulation/gamesystem
May 26, 2023
-
smb2fs.lha - network/samba
May 26, 2023
-
cpubench.lha - utility/benchmark
May 26, 2023
-
sploinergui.lha - utility/workbench
May 26, 2023
-
amigaamp3.lha - audio/play
May 23, 2023
-
warpdtprefs.lha - datatype/image
May 22, 2023
-
hwp_apng.lha - library/hollywood
May 22, 2023
|
|
|
|
Re: Double heigh screen and normal window on
|
Posted on: 2022/5/22 7:54
#61
|
Just popping in 
|
@kas1e Quote: Thanks for point, i tried, but it's the same :( Hmm, I was hoping that would help. Can you at least move the window to the proper location with MoveWindow() or ChangeWindowBox() after it's been opened?
|
|
|
|
Re: Double heigh screen and normal window on
|
Posted on: 2022/5/21 4:11
#62
|
Just popping in 
|
@kas1e Perhaps WA_AutoAdjust is altering the location of your window? Here's what the autodocs have to say about it: Quote: WA_AutoAdjust - a Boolean attribute which says that it's OK to move or even shrink the dimensions of this window to fit it on the screen, within the dimension limits specified by MinWidth and MinHeight. Someday, this processing might be sensitive to the currently visible portion of the screen the window will be opening on, so don't draw too many conclusions about the auto-adjust algorithms. Also see WA_AutoAdjustDClip below. (Normally, this attribute defaults to FALSE. However, if you call OpenWindowTags() or OpenWindowTagList() with a NULL NewWindow pointer, this attribute defaults to TRUE).
Since you're not using a NewWindow, WA_AutoAdjust defaults to TRUE. It might be confused by the double-height screen, and ends up putting the window where it thinks it's visible. Try adding WA_AutoAdjust, FALSE, and see if that helps.
|
|
|
|
Re: MineCraft (MineTest) work in progress help need it
|
Posted on: 2022/5/14 7:35
#63
|
Just popping in 
|
@kas1e I'd assume that for compatibility reasons malloc() uses MEMF_SHARED. If it didn't, you'd expect to get a DSI when some other task/thread tried to access the semaphore. Quote: But what Andrea mean it should be something like : You could also allocate the entire isem_t using AllocVecTags(), instead of just the SignalSemaphore. That way, you wouldn't need to change any of the other semaphore code to work with pointers to objects instead of embedded objects (I assume you made those changes when you tested Andrea's suggestion). SignalSemaphores (and Lists) can also be allocated using AllocSysObjectTags(), which presumably initializes them for you. You'd again be working with pointers to objects. I suspect that none of that will make a difference, but it might be worth a try if further debugging doesn't turn up anything. Quote: Not sure through how/what it mean It sounds like they're suggesting that if we have a working implementation of std::counting_semaphore (do we?) that we could look at the source code for that and see how it's implemented compared to how libpsem did it.
|
|
|
|
Re: MineCraft (MineTest) work in progress help need it
|
Posted on: 2022/5/13 2:28
#64
|
Just popping in 
|
@kas1e Quote: I never use anywhere posix semaphores, it is first time i meet with them in minetest. Frederik made this library exactly when i ask about in this thread and then fixing it few times. Ah, so it doesn't have the history behind it that I was expecting. Still, from at least a casual examination of the code, I don't see anything that looks like it would cause a major system lockup, as long as it's getting valid data to work with. That's not the same as saying I'm sure there's nothing wrong with it, but I'd still check those other two possibilities first. Quote: Question is how to find it without debugger, what to prinfs and where. Having a working debugger would be nice, though a hard system crash would probably kill the debugger, too. Unfortunately, there's no simple way to check for the first possibility (corruption of the underlying sem_t). The sem_t contains embedded Exec SignalSemaphore and List structs, rather than pointers to them, so you'd need to DebugPrintF() a bunch of fields in those structs to try to determine if they are corrupt or not. You could at least dump isem->value and see if it looks reasonable (it should probably be zero). You could also add some "made it to this point"-style DebugPrintF()s inside sem_post(), to try to determine where in that function the crash occurs. For the second possibility (the code being triggered by the semaphore is what crashes) you'd need to locate the code that's waiting on the semaphore that's being posted to; something like "m_send_sleep_semaphore.wait()". Then you could add some "made it to this point"-style DebugPrintF()s both before and after the wait, to see if the code actually exits the wait before the crash occurs. If it does, you can move the DebugPrintF()s further along in the code to try to narrow down where the crash happens.
|
|
|
|
Re: MineCraft (MineTest) work in progress help need it
|
Posted on: 2022/5/12 2:15
#65
|
Just popping in 
|
@kas1e
The code for sem_post() isn't terribly complicated. Since the same code seems to work most of the time (and presumably in other projects as well), I'm guessing that's not where the problem lies. So two possibilities come to mind.
1. The semaphore (sem_t) that's being passed to sem_post() is getting clobbered by something. sem_post() makes a number of Exec calls, passing pointers obtained from the semaphore. If one or more of those pointers is invalid, it could potentially cause a crash.
2. Presumably there's another thread somewhere that's sem_wait()ing on the semaphore. That thread wakes up when sem_post() posts to the semaphore, and that thread does something that causes the crash. The crash is not caused by the post, it's just triggered by it.
|
|
|
|
Re: MineCraft (MineTest) work in progress help need it
|
Posted on: 2022/5/11 3:44
#66
|
Just popping in 
|
@kas1e Quote: But what i can see there, that it take "int" as input, and then signals semaphores, but we do call it from Trigger() without any value, just as "post()" , so maybe something wrong there .. num is given a default value of 1 in the declaration of Semaphore:
void post(unsigned int num = 1);
So if you call post() without a parameter it should use the default. You could add a printf to confirm that. The problem is probably in the call to sem_post(&semaphore);.
|
|
|
|
Re: Show your AmigaOS 4.x computer or Workbench!
|
Posted on: 2022/5/11 3:11
#67
|
Just popping in 
|
@trixie
Hey, E-mu! I applied for a job there once, way back when.
|
|
|
|
Re: SnoopDos causes a DSI error
|
Posted on: 2022/4/29 6:47
#68
|
Just popping in 
|
SnoopDos does have a nicer user interface, though that's no help if the basic functionality doesn't work.
One SnoopDos feature I really miss on Snoopy is the ability to easily enable or disable all of the function monitors. When first starting to debug something and I have no idea what's wrong I often like to enable everything, and then disable selected functions afterwards if logging them gets in the way. That was one button on SnoopDos, but involves manually selecting a slew of items across multiple submenus with Snoopy.
It would be nice if there were "Enable All" and "Disable All" menu selections, at least for the DOS Functions menu. And perhaps a "Default Settings" (or "Saved Settings") selection as well, to easily get back to the starting point.
|
|
|
|
Re: Internet speed test that works in Odyssey?
|
Posted on: 2022/4/16 4:20
#69
|
Just popping in 
|
@ktadd I found this one some years ago, and it's always worked well for me: testmy.net
|
|
|
|
Re: Bug in Newlib Header?
|
Posted on: 2022/3/31 0:15
#70
|
Just popping in 
|
@Raziel, @walkero Quote: I think that's what msteed described as a solution that worked for him as well. Yes, that's exactly what I did. The bug seems to be something that's rarely encountered, since it's been around for some time (it was in at least the previous version of the SDK (53.30), too).
|
|
|
|
Bug in Newlib Header?
|
Posted on: 2022/3/30 7:49
#71
|
Just popping in 
|
I believe I've stumbled across a bug in one of the newlib header files (the ones from the most recent SDK). I was trying to compile GIFLIB, where one of the files has the following bit of code:
#ifndef SIZE_MAX
#define SIZE_MAX UINTPTR_MAX
#endif
It compiled fine when using clib2, but when using newlib I got the following error when SIZE_MAX was referenced:
In file included from openbsd-reallocarray.c:8:
openbsd-reallocarray.c: In function 'openbsd_reallocarray':
openbsd-reallocarray.c:25:19: error: 'ULONG_MAX' undeclared (first use in this function)
nmemb > 0 && SIZE_MAX / nmemb < size) {
^~~~~~~~
openbsd-reallocarray.c:25:19: note: 'ULONG_MAX' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'?
openbsd-reallocarray.c:10:1:
+#include <limits.h>
The file indeed does not include <limits.h>, but it does include <stdint.h>. The clib2 version of <stdint.h> contains the following:
#ifndef _LIMITS_H
#include <limits.h>
#endif /* _LIMITS_H */
So <stdint.h> includes <limits.h>, and everything works fine. The newlib version of <stdint.h>, however, contains the following:
#if defined(__GNUC__) && \
( (__GNUC__ >= 4) || \
( (__GNUC__ >= 3) && defined(__GNUC_MINOR__) && (__GNUC_MINOR__ > 2) ) )
/* gcc > 3.2 implicitly defines the values we are interested */
#define __STDINT_EXP(x) __##x##__
#else
#define __STDINT_EXP(x) x
#include <limits.h>
#endif
In other words, <limits.h> is included only if the version of GCC is 3.2 or earlier. That seems odd, which makes me think that "#include <limits.h>" should come after the #endif, not before it. I made this change, and was able to build GIFLIB without error. I recompiled a number of my other projects, and nothing seems to have been broken by the change. But the flow of system headers can be complex and difficult to follow, so I thought I'd see if others can confirm that this is a bug, or explain why it isn't.
|
|
|
|
Re: SDL2
|
Posted on: 2022/3/14 5:53
#72
|
Just popping in 
|
@Raziel Quote: NumLock doesn't produce a RAWKEY event, but the key itself does with different values. Ah, I see. You're right, when a numpad key that varies with the NumLock state is pressed, it's possible to deduce the state- if you get a '0' from the numpad then NumLock must be on, and if you get an 'Insert' it must be off. That won't work with numpad keys like '5' and '+' that don't vary with the NumLock state though, and of course someone has to press a numpad key before you can update the state. That might be good enough, depending on what you're looking to do with the NumLock state, but it's not a general purpose way to know the current state.
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/12 7:18
#74
|
Just popping in 
|
Quote: "If an error is generated, no change is made to the contents of params." Given that, it would be good defensive programming practice to set 'status' to 0 before making the call, so if the call aborts without setting the status at all then at least you'll get a consistent failure, rather than a random result depending on what happens to be on the stack. That would have saved kas1e a lot of time playing with printf().
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/6 7:50
#75
|
Just popping in 
|
@kas1e
What if you put the printf() or Delay() at the very beginning of your function, before making any of the SDL calls? Does it work there? What if you put it at the very end, just before the "return SDL_TRUE;"? (Which means it won't even be called if compiling the shaders fails.) Or does it have to be in between the two sets of SDL calls in order to make a difference?
And what if you use IExec->DebugPrintF() rather than printf()?
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/3/6 7:33
#76
|
Just popping in 
|
I waited for a bit in case anything else came up, but nothing did. So I've released version 1.1 of Profyler, which adds a workaround for the bug in ObtainDebugSymbol() and so can now display the source file name and line number for every profiled function.
The workaround shuts off starting with Exec version 54.47, so hopefully the bug fix will be present in that version when it appears.
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/3 3:41
#77
|
Just popping in 
|
@kas1e
Remember that while printf() looks simple in the source code, there's a lot going on under the hood, involving the console (which decides where the printed text goes), the graphics library (which renders the font characters into pixels), and the graphics card driver (which gets the pixels to the screen).
Somewhere in all of that there's almost certainly something that has to Wait(), which gives other tasks a chance to run. So printf() doesn't just take some time to execute. but it also allows other tasks to run. Your for() loop takes time, but most likely doesn't cause a task switch (assuming the delay isn't so long that it's preempted). Calling Delay() of course also allows other tasks to run, without all the other complexity of printf().
I'm not a 3D graphics guru, so I have no idea what those graphics calls are doing. But if it involves another task that's running asynchronously, then letting that task run while you're delaying may give it a chance to complete some necessary work that doesn't get done in time otherwise.
|
|
|
|
Re: Is there a simple why to find the motherboard name?
|
Posted on: 2022/3/3 3:13
#78
|
Just popping in 
|
@LiveForIt It's not precisely what you asked for, but the autodoc for version.library has this table for the version number of version.library itself:
AmigaOS release | version.library
-----------------------------------------+----------------
3.5 | 44.2
3.9 | 45.1
3.9 Boing Bag 1 | 45.2
3.9 Boing Bag 2 | 45.3
4.0 | 50.2
4.0 Update 1 | 51.1
4.0 Update 4 | 51.4
4.0 Update 4 (CyberStormPPC/BlizzardPPC) | 52.2
4.1 | 53.1
4.1 Update 1 | 53.2
4.1 Update 2 | 53.3
4.1 Update 3 | 53.7
4.1 Update 4 | 53.8
4.1 Update 5 | 53.10
4.1 Update 6 | 53.11
4.1 Update 7 (unreleased) | 53.12
4.1 Update 8 (unreleased) | 53.13
4.1 Final Edition | 53.14
4.1 Final Edition Update 1 | 53.15
4.1 Final Edition Update 2 | 53.17
4.1 Final Edition Update 2 HotFix | 53.18
|
|
|
|
Re: Amigans.net 2022 updates
|
Posted on: 2022/3/3 3:05
#79
|
Just popping in 
|
@walkero
I saw this same thing once a few days ago, when visiting as a guest (not logged in)- news items from 2006 or 2007, and if I scrolled down to the bottom of the home page the page selection buttons had me on some page number in the hundreds, instead of page 1.
I don't remember what I did to fix it- I think I just clicked on 'Home', but I may be remembering wrong. I imagine I could have clicked on the page 1 button, too.
I haven't seen the problem since, so it's not readily reproducible.
|
|
|
|
Re: x5000 benchmarks / speed up
|
Posted on: 2022/2/19 3:52
#80
|
Just popping in 
|
@geennaam
Any chance I could get a copy of your benchmark program? I'm curious what the X1000 numbers would be.
|
|
|
|