Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Raven_Singularity

Pages: [1] 2 3 ... 11
1
If I were you, I'd download 1.5 and see if the error still appears.

After the absolute nightmare I went through trying to get QB64 to work correctly on my 4K display originally (editor fullscreen issues, font scaling issues, font glitching issues), I'm hesitant to upgrade in case it messes it all up again.  I don't need any of the new features for my current project, and this bug is easily worked around by using INTEGER instead of _UNSIGNED _BIT.

If it is a v1.5 bug, then the devs can check it out.


Edit:
It says you're a QB64 dev, I imagine it would be easy enough for you to try 4 lines of code in your QB64.

2
Closest I ever got to any of those was one by Activision - since you didn't list it, it must not be of interest.

Here it is anyway: Frostbite https://www.qb64.org/forum/index.php?topic=342.msg2278#msg2278

That's a very cool game!  I've never played the original, but your game looks like an emulator.  I got to level 3 after a few tries, scored 2220 points.  It's a tough little game, like most games of that era.  It reminded me of playing Frogger and Burger Time.  It's more complex than Frogger (with the hypothermia), but less complex than Burger Time.

3
QB64 Discussion / Re: Terror in the hypermaze
« on: April 09, 2021, 07:16:41 am »
This is pretty crazy looking.  I have no idea what's going on.  Why are hoards of emoticons attacking you?

4
QB64 Discussion / Compiler fails on _UNSIGNED _BIT function parameters
« on: April 09, 2021, 07:06:43 am »
This code fails to compile in QB64 v1.3:

Code: QB64: [Select]
  1. PRINT foo$(0)
  2.  
  3. FUNCTION foo$ (my_variable AS _UNSIGNED _BIT)
  4.  
  5.    foo$ = "something"
  6.  


It also fails when using a variable suffix:

Code: QB64: [Select]
  1. PRINT foo$(0)
  2.  
  3. FUNCTION foo$ (my_variable~`)
  4.  
  5.    foo$ = "something"
  6.  


I thought maybe the "0" being passed in to my function was not being seen as an _UNSIGNED _BIT, but it still fails when using a typed variable:

Code: QB64: [Select]
  1. DIM UnsignedBit AS _UNSIGNED _BIT
  2.  
  3. UnsignedBit = 0
  4.  
  5. PRINT foo$(UnsignedBit)
  6.  
  7. FUNCTION foo$ (my_variable AS _UNSIGNED _BIT)
  8.  
  9.    foo$ = "something"
  10.  


Could someone test if that fails on QB64 v1.5?

I read the QB64 v1.4 and v1.5 changelog and decided an update wasn't needed for my current small project.


The error from the compiler is this:

Code: [Select]
In file included from ..\\temp\\main.txt:23,
                 from qbx.cpp:2171:
..\\temp\\data1.txt: In function 'qbs* FUNC_FOO(unsigned int*)':
..\\temp\\data1.txt:3:9: error: declaration of 'unsigned int* _FUNC_FOO_UBIT1_MY_VARIABLE' shadows a parameter
 uint32 *_FUNC_FOO_UBIT1_MY_VARIABLE=NULL;
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.

I read online that "shadows a parameter" has to do with a function parameter using the same name as a variable in the function, but it's failing on an empty function.


Breaking down the error message I can see:

Code: [Select]
_FUNC_FOO_UBIT1_MY_VARIABLE   unsigned int*
_FUNC_FOO_UBIT1_MY_VARIABLE   uint32*

I'm not super familiar with the C++ variable types, but it looks like there are two separate types of unsigned integers being used by QB64 in different areas, which is causing the compiler to interpret them as separate variables.


Questions:
  • Are _UNSIGNED _BIT variables not intended to be passed to FUNCTIONs?
    If so, it would be to have QB64 catch this error in the editor.
  • Or is there something else I'm missing in the way I'm calling the function?

5
From my personal experience, most USB keyboards top out at 6KRO, while you need a PS/2 keyboard for NKRO usage.

Really?

I've never encountered a PS/2 keyboard that could handle even 4 simultaneous keys down, unless the keys included the standard modifiers (Ctrl, Alt, Shift).  Haven't seen a PS/2 keyboard that could handle A+B+C+D.


Edit:
Thanks for the link.

6
QB64 Discussion / Re: RND and RANDOMIZE information
« on: June 12, 2019, 07:57:28 pm »
It has been decades since I was doing this in QB45, but I know it works, because I was reusing a fixed seed to draw my level screens.  Every time I came back to the screen, it had the same random number sequence.

Pretty sure I was just using this each time to reset it:

Code: QB64: [Select]
  1. RANDOMIZE MySeed

I'm unable to test on QB45 at the moment.  Can someone else test it?

I've never used RANDOMIZE USING before.

7
QB64 Discussion / Re: [Bug ?!] _RGB32 issue with CONST
« on: June 12, 2019, 12:12:21 pm »
^ Thanks for the detailed explanation.  Fascinating.  I can see the issue with line numbering now.

8
QB64 Discussion / Re: INKEY$ in console mode
« on: June 12, 2019, 12:09:28 pm »
Just write a low-level keyboard driver.  :clownface:


Edit:
To be clear, this was a joke, not an actual suggestion.  :-)

9
Just to add to this:

The number of simultaneous key-downs that a system can handle is determined by the actual keyboard hardware.  The most advanced USB keyboards allow detection of key up/down states for EVERY key simultaneously.  With cheap keyboards, sometimes even 3 simultaneous keypresses can fail!  All keyboards can handle Ctrl, Alt, Shift combinations because OSes so commonly use them as modifiers, but once you get into uncommon combinations like A+B+C, it's much less likely to register the keypresses.

Also to note, PS/2 and the original keyboard connectors physically limit how many keypresses can be sent simultaneously.  USB keyboards, in theory, have no such limits, but in practise most cheap USB keyboards emulate PS/2 under-the-hood, along with their crappy limitations.  Gaming keyboards often advertise how many keys can be held down simultaneously, though some lie about this!  My current piece-of-shit Amazon Basics keyboard is terrible for this, it often fails with three-key combos, despite saying it can handle 128 simultaneous keys or some rubbish.

Back in the day I can remember trying tons of key combos to figure out which could be handled for multiplayer gaming on the same keyboard.  It was tricky to find keys that wouldn't block each other.

10
QB64 Discussion / Re: RND and RANDOMIZE information
« on: June 12, 2019, 11:50:38 am »
Ha! I am using variable length strings in custom type now to save small integer arrays (hands by card index) in Blackjack thread.

That's like the inverse of what I'm doing, lol.


We can do variable length strings in Type definitions now v1.3 :)

Oh, really?

I started on v1.2 and only recently upgraded to v1.3.

I guess I can clean my code up a bit!  Thanks for the tip.

11
QB64 Discussion / Re: Thank You For This!
« on: June 12, 2019, 11:42:19 am »
When I code in Basic, I can lose track of time. When I code in C/C++, time just stands still.

Agreed!  I've lost endless hours in BASIC, and it always feels warm and cozy.  I find in other programing languages I spend too much time debugging or working around quirks and oddities, usually a lot more time spent debugging than coding.  BASIC tends to be more consistent, and rarely has bugs that take me more than a couple hours to solve.


A few years back, "Clippy" offered $1000 to anyone who could get QB64 to port to Android, seamlessly. No takers.

I would assume it would take several times that much to make it worthwhile.  Hence me asking.  :-)


Android keyboard, touchscreen, etc. would also have to be incorporated in QB64, to make it worth running on an Android device.  I doubt you will find anyone with the time around here, or all the knowledge needed, to accomplish what you are asking for.

Straight ports of mouse-based apps to Android do work -- such as SDL-based apps -- as long as there's no use of right-click, middle-click, or mousewheel.  For my usage case, left-click would be fine.  I also don't need to have custom Android touchscreen features added, like long-press, pinching, multi-touch, etc.

12
QB64 Discussion / Re: RND and RANDOMIZE information
« on: June 12, 2019, 11:31:09 am »
I used Randomize seed to avoid having to array all the data of for tracking "tails" of a firework burst. Type Structures don't do arrays (yet) so I used a seed for Randomize.

Ah, nice.

I had to work around not being able to store an array of variable-length strings in a custom data type recently.  In my case, I created an array of strings separately, then in the data type I had an integer referencing the element in the string array.  Not as clean code, but gets the job done!

13
QB64 Discussion / Re: [Bug ?!] _RGB32 issue with CONST
« on: June 12, 2019, 11:24:49 am »
Why would three CONST separated by colons ":" be any different than having three CONST on different lines?

I always thought ":" was equivalent to a new line.

14
QB64 Discussion / Re: IDE Improvement Proposal
« on: June 12, 2019, 11:20:43 am »
I'm going to the FILE - OPEN subdirectory and then to the source code. If OUTPUT EXE TO SOURCE FOLDER is selected when IDE start, then the source in the subdirectory works correctly. If this is not selected when IDE start and I select OUTPUT EXE TO SOURCE FOLDER in menu, but I do not make any further modifications in source code, it is then compiled as if I had not changed anything - as is set when the IDE starts without updating this setting.
 In short, I want the IDE to respond to changes in the menu without the user having to click on the code and press something for activate the changes set in the menu.

Thanks for the clarification.

15
QB64 Discussion / Re: RND and RANDOMIZE information
« on: June 12, 2019, 11:17:44 am »
Fireworks, landscapes, water reflections, and reusing random number sequences?

Sign me up!  I'll check it out once I'm back on Desktop, sounds very cool.

Are you reusing the random sequence to recreate the same firework as a reflection in the water?

Could you not just draw the firework twice at the time of generating the random numbers?

Pages: [1] 2 3 ... 11