Recent Posts

Pages: [1] 2 3 ... 10
1
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« Last post by johannhowitzer on Today at 05:06:53 AM »
The standard practical use of DISPLAY is once per frame in your main gameplay loop, so you can draw everything behind the scenes, and have the screen update all at once.  For QB64 game developers, it is essential for anything above a text adventure, without it, you will see crazy flickering.  But once per loop is not terribly expensive.

Regarding MEM, if I have to resort to essentially learning to code assembly for a single visual effect, that visual effect might have to get scrapped.  I'm already putting off learning another programming language until the demo is done.  I was hoping there was a workaround with some clever trick.
2
QB64 Discussion / Re: Problem with CLEAR
« Last post by bartok on Today at 04:49:19 AM »
The problem I have found about CLEAR, at the end was very simple to be fixed. I needed to define T AS STRING, but I solved defining T AS SINGLE  (and even INTEGER is working) and then converting it in string with _LTRIM and STR$. But, when the code starts to be long and complicated, like the mine with 12 subroutines and almost 2000 lines, it becomes difficult to distinguish if the problem is about something wrong somewhere in the code, or a bug. Generally, 999 every 1000 times the problem is something wrong in the code, so one doesn't think about a bug and finishes to spend much time in searching an error. Finally, one can suppose a bug, but even in this case, it is impossible to know that the problem is in something apparently separate: how one can suppose that there is a conflict between CLEAR and defining a string in TYPE?

Even when I wrote the first post, I was not thinking about a bug in CLEAR, and I was convinced that there was someting wrong in the code, or maybe a wrong use of CLEAR. I found the bug only cutting the first example in order to make it more understandable for you. And, as you say that CLEAR is buggy, maybe there are other bug in it.

I think that it will be nice if CLEAR will be fixed, because I think that it is not a marginal command, as RUN, but a very important one: it is common that a program has to restart itself without exiting and rerun it, so it is important to have a simple and well working command that clear all variables without the necessity to create specific routines to do it.
3
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« Last post by NOVARSEG on Today at 04:34:00 AM »
In theory you could draw a ship with MEM.   I'm not so sure that alpha channel will allow a total fade out to black for example.

MEM seems to be very fast and is the closest thing to assembler in QB64.  If a ship can be moved with MEM then any effect is possible.

Some code using MEM to draw custom cursors. very basic.   

https://www.qb64.org/forum/index.php?topic=3809.15

Another thing that seems to slow down code is DISPLAY.  With MEM I did not have to use DISPLAY (well I don't understand it anyway)
4
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« Last post by johannhowitzer on Today at 04:02:36 AM »
It doesn't go from 0 to 1, then back to 0 some frames later...  it goes to 1, then gradually goes away over about 15 frames, a quarter second.  And I have various flashes - red for low health, white for being hit, blue for engine burnout.

Also, I have other modifiers going on with my sprite sheet already - tilt up or down, animation frames, etc.  Having to duplicate my entire sprite sheet, color everything red, then use another modifier, that's a ton of extra busywork for a single-color effect.  I wouldn't just have to color each ship red once, I'd have to color every animation frame three times for every color overlay I want.
5
QB64 Discussion / Re: What's Steve been doing?
« Last post by Galleon on Today at 01:13:43 AM »
Glad your aunt has come to help
6
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« Last post by Galleon on Today at 01:01:43 AM »
Keep multiple images of same sprite in memory, one with red, one without
Prepare them once when your program loads, then use them whenever needed
This technique will also make the transition to hardware-based images (33) easier later
7
Programs / Re: Fantasy
« Last post by Juan Tamarit on Today at 12:57:00 AM »
Thank you guys. I solved it. Just a +1 after the second FREEFILE. But i understand what you say: until i don't use the handle for opening the file it won't give me a new one, right? That's why this +1 trick works, isn't it? Ok, i'll switch the order for fitting. Thanks again
8
Programs / Re: Fantasy
« Last post by NOVARSEG on Yesterday at 11:15:37 PM »
The clue was here

Quote
I'm having an error that stands "file already open", particularly in line "OPEN "tmp.txt" FOR OUTPUT AS #destFile&".



9
Programs / Re: Fantasy
« Last post by FellippeHeitor on Yesterday at 11:01:01 PM »
NOVARSEG is correct. The FREEFILE function won't return a new handle unless the previous one it output is actually used to open a file.
10
Programs / Re: Fantasy
« Last post by NOVARSEG on Yesterday at 10:55:49 PM »

Hi Juan Tamarit

This is just a guess because I have not tested the code

Quote
  • orgFile& = FREEFILE 'we need two filehandles: one for origin file,
            destFile& = FREEFILE '       and another for destination file
            OPEN "town.txt" FOR INPUT AS #orgFile& '    e will extract info from this file
            OPEN "tmp.txt" FOR OUTPUT AS #destFile& '
[/size]


orgFile& = FREEFILE 'we need two filehandles: one for origin file,
       
OPEN "town.txt" FOR INPUT AS #orgFile& '    e will extract info from this file
       
destFile& = FREEFILE '       and another for destination file

OPEN "tmp.txt" FOR OUTPUT AS #destFile& '


Pages: [1] 2 3 ... 10