QB64 Phoenix Edition v3.12.0 Released!

[RhoSigma]

Really nice enhancements & fixes.

Just a question on _ReadFile$ and _WriteFile
What is the maximum size of file they can handle?

and related to that more in general: What is the largest string you can define in qb64pe ?
I seem to get only 2GB in mydata$, are there ways to go bigger then that?

2GB is the string limit (Variable Types), but I guess in the 32-bit Windows version it will be even less. I doubt the file system will impose any limits here on todays current OS's.

However, I always wonder again about this kind of questions. What kind of files you guys try to deal with? Even my largest MP4 video file is with approx. 350MB far below the 2GB limit.

[SMcNeill]

I've got some database files which I routinely work with that are around 7GB in size.

Those can't be loaded into a string, but you can reserve memory for them and load them into a _MEMNEW block, as long as you load them in "chunks" until that block is fully filled.  That is:

1) Provided you're on a 64-bit machine.  32-bit limits you to about 1.5GB max file size.  (It claims 2GB, but every file has to reserve some overhead for the OS.)

2) Provided you have more than that amount of memory on your system.

3) Provided that taking that much memory from your system doesn't steal resources from other things and brick up your machine until you reboot.

[mdijkens]

I know regular string are 2GB max and arrays can by up to RAM limit.
But I thought I once found a way to have bigger strings, but maybe that was in another life :-)

Yes I normally read in blocks of 4MB (on average fastest) with files over 100GB :-)
Somewhere on the forum I already explained that a lot of my utilities are about dealing with huge (log)files: conversion, splitting, concatenating, extraction, counting etc. and QB64 is great for that

This is one of my most used functions that works extremely fast:

Code: (Select All)

Function BIG.read& (fileName$, eol$) ' 4M lines/sec
  Const BLOCKSIZE = 4194304 '=64*65536 = 4 MB
  If Not _FileExists(fileName$) Then CSV.read& = 0: Exit Function
  eoll% = Len(eol$)
  Dim block As String * BLOCKSIZE
  ff% = FreeFile
  Open fileName$ For Binary Access Read As #ff%
  blocks& = LOF(ff%) \ BLOCKSIZE: blocks& = blocks& - ((LOF(ff%) Mod blocks&) > 0)
  sep& = 0
  lines& = -1
  $Checking:Off
  For curblock& = 1 To blocks&
    Get #ff%, , block
    If curblock& > 1 Then
      buf$ = Mid$(buf$, sep&) + block
      r0& = InStr(buf$, eol$) + eoll%
    Else
      buf$ = block
      r0& = 1
    End If
    r1& = InStr(r0&, buf$, eol$)
    Do While r1& >= r0& And r0& > 0
      lin$ = Mid$(buf$, r0&, r1& - r0& + eoll%)
      ret% = BIG.line(lin$) ' Process lin$
      lines& = lines& + 1
      sep& = r1&: r0& = r1& + eoll%: r1& = InStr(r0&, buf$, eol$)
    Loop
  Next curblock&
  $Checking:On
  Close #ff%
  buf$ = ""
  BIG.read = lines&
End Function

[SpriggsySpriggs]

Well these new updates do seem rather cool. Looking forward to testing some of them in a future project.

[bplus]

I am noticing a big difference in the quality of print when I use Lucon.ttf at 18 pixels that Terry first showed us:
Here I show v3.10 print (left) versus v3.12 print (right side).
   

So was something changed in the way of handling fonts in IDE?

[a740g]

I am noticing a big difference in the quality of print when I use Lucon.ttf at 18 pixels that Terry first showed us:
Here I show v3.10 print (left) versus v3.12 print (right side).


So was something changed in the way of handling fonts in IDE?

Well, we moved to the current version of FreeType (2.4.12 to 2.13.2). The one that we had before was from 2013.

[TerryRitchie]

I am noticing a big difference in the quality of print when I use Lucon.ttf at 18 pixels that Terry first showed us:
Here I show v3.10 print (left) versus v3.12 print (right side).


So was something changed in the way of handling fonts in IDE?

Well, we moved to the current version of FreeType (2.4.12 to 2.13.2). The one that we had before was from 2013.

I can confirm the same text anomaly in Windows 7 64bit.

First image is version 3.11.0

Second image is version 3.12.0

[SMcNeill]

I swear, you guys have better eyes than me.  If this was a game of spot-the-difference, I'd lose.  Ijust can't tell any change in those words.  What's different aboutthem?  What am I missing?  LOL!

[TerryRitchie]

I swear, you guys have better eyes than me.  If this was a game of spot-the-difference, I'd lose.  Ijust can't tell any change in those words.  What's different aboutthem?  What am I missing?  LOL!

Look at the capital Ms and Ns in the text. The left vertical legs of each is very thin. This happens with other vertical lines as well, but is easily seen in the Ms and Ns. Horizontal lines seem to be affected too to a lesser degree.

Bplus' images show a much more degraded lettering than mine though. The difference between operating systems perhaps?

[SMcNeill]

MY poor eyes might not be able to tell the difference normally, but you can certainly see the change if you place both pictures side-by-side!

Code: (Select All)

Screen _NewImage(1280, 720, 32)



image1 = _LoadImage("z:\3.11.0.png", 32)

image2 = _LoadImage("z:\3.12.0.png", 32)

_PutImage (0, 0)-(639, 719), image2

_PutImage (640, 0)-(1279, 719), image1

Sleep

_PutImage (0, 0)-(638, 719), image1

_PutImage (640, 0)-(1278, 719), image2

---

What I'm more curious about at the moment, however, is how the heck did you generate two different size images?

   

I'd imagine you just used _SaveImage to generate those two images.  Am I right?

If so, why the heck is one 779 pixels tall while the other is 780?