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 - jonza

Pages: [1]
1
QB64 Discussion / Re: Compiled programs on Linux problem (-no-pie switch) solved.
« on: March 28, 2019, 05:46:19 am »
Found a solution here:
https://www.qb64.org/forum/index.php?PHPSESSID=890c711e474b65cf86cca857cbc6ddbb&topic=326.msg2174#msg2174

Change lines 57 & 58 to:
typedef __uint64_t uint64_t;
typedef __int64_t int64_t;

Edit: In file internal/c/parts/audio/decode/mp3_mini/src/libc.h

2
QB64 Discussion / Re: Compiled programs on Linux problem (-no-pie switch) solved.
« on: March 27, 2019, 09:51:29 am »
If I comment out everything sound related it works. Regular installation starts to nag about fonts after that. I also tried the dev build. Same coode works perfectly in Windows.

Might not be a dependency problem, but I have at least  libasound2, -data, -dev, -plugins ; freeglut3-dev ; libglew-dev ; libglm-dev ; libsdl1.2-dev; libsdl-image1.2-dev; libsdl-mixer1.2-dev; libsdl-net1.2-dev; libsdl-ttf2.0-dev

Any other dependencies I don't know about?

3
QB64 Discussion / Re: Compiled programs on Linux problem (-no-pie switch) solved.
« on: March 27, 2019, 09:21:00 am »
I used your installer, but still have the same problem.

C++ Compilation failed check....

/usr/include/x86_64-linux-gnu/bits/stdint-uintn.h:27:20: note: previous declaration of ‘uint64_t’ was here
 typedef __uint64_t uint64_t;
                    ^~~~~~~~
In file included from ../../src/minimp3.c:24:0:
../../src/libc.h:58:37: error: conflicting types for ‘int64_t’
         typedef   signed long long  int64_t;
                                     ^~~~~~~
In file included from /usr/include/stdint.h:34:0,
                 from /usr/lib/gcc/x86_64-linux-gnu/7/include/stdint.h:9,
                 from ../../src/libc.h:26,
                 from ../../src/minimp3.c:24:
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous declaration of ‘int64_t’ was here
 typedef __int64_t int64_t;
/opt/qb64/internal/temp/compilelog.txt/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous declaration of ‘int64_t’ was here
 typedef __int64_t int64_t;
/opt/qb64/internal/temp/compilelog.txt/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous declaration of ‘int64_t’ was here
 typedef __int64_t int64_t;
                   ^~~~~~~
ar: temp/minimp3.o: No such file or directory
:

4
QB64 Discussion / Re: How to optimize for speed?
« on: December 11, 2018, 12:59:33 am »
Quote from: SMcNeill on November 29, 2018, 10:46:40 am
POINT is pointlessly slow.  Use the _MEM commands instead.

DIM M AS _MEM
M = _MEMIMAGE(0) 'for the display screen

Then in your loop use the following instead of point:

IF _MEMGET(M, M.OFFSET + (X * 1366 + Y) * 4, _UNSIGNED LONG) = _RGB32(0,0,0) THEN something = something + 1

And to break that down for you:

M Is the memory block we want to get data from
M.OFFSET is where the screen data starts in memory.
X * 1366 + Y represents the pixel placement in memory.
*4 is because you're using 32 bit color screens.  There's one byte for each Red, Green, Blue, Alpha value.
_UNSIGNED LONG is how we tell MEMGET to return the 4 color values back to us all at once.

Thanks. I'll definitely do this. Actually I'm not reading anything from the screen, just displaying the game there, so the the screen hardware size should not matter. My layer count and level size is getting higher all the time(if I really implement all secondary stuff I want) so I't seems I might go 8-bit just to save ram.

It's going to be a Fallout 3 and Donald Trump inspired tragically comical post-apocalyptic sandboxed rpg platformer metroidvania game.

5
QB64 Discussion / How to optimize for speed?
« on: November 29, 2018, 09:50:14 am »
Hi!

I've been coding a platformer game in qbasic for the first time in something like 20 years. I used _LIMIT 60 for timing, but was suprised when commenting it out didn't speed up the game.

I have 4 800x480 32bit screens: invisible one for floor collisions, nicer looking one for the visible level and one for sprites, and one where I copy everything except the collision layer. Then there's the 1366x768 sized one where everything is shown. I use _PUTIMAGE to layer everything. After that I copy and resize a 320x180 sized rectangle from there and _PUTIMAGE it to my 1366x768 screen. I refresh the screen with _DISPLAY. I use point maybe 6-8 times a loop.

like:
if POINT (x,y)=_rgb32(0,0,0) then something=something+1

Is might just be my wasteful usage of _PUTIMAGE. Any other ideas?

Just seems weird that I made a lot faster platformers with my 386sx and QuickBasic 4.5, with some external libraries. Of course it was just 4 pages of screen 13, but anyway.... you know... my current computer is quite old, but it does run Fallout 3 on high :)

Pages: [1]