I've been trying to come up with some interesting transitions for an image slideshow (family album thing).  I have the regular fades and slides and swaps worked out, trying to get something fancier.  Here's something I thought of using rotozoom - break image up to pieces and drop them off the screen, revealing the other one. 

It's a mess.  Seems to work but thought I'd share it now to get some feedback/help with making it better.  Perhaps there's a better way to do this?   (There's 2 rotozoom subs in the code to compare them)

- Dav

Bug Report.

At the top of my code I have the '$DYNAMIC switch.
I have a sub that takes an array as a parameter.
In that sub I REDIM that array.
The code compiles fine.
When run the compiled code I receive an Unhandled Error message for a Duplicate Definition on the line where I REDIM the array. It asks if I want to continue Yes/No. This shouldn't happen. It is a bug with the current version of QB64. It didn't happen in QB4.5.

TR

Code to modify and create INI files with qb64.
Usage
AddINI "FileName","Section","Key","Data" This adds, modifies or creates data in either a new ini file or edits an existsing one
DelINI "FileName","Section","Key" This deletes a specific key in an ini file
DelSec "FileName","Section" This Removes an entire section from an ini file
x$ = ReadINI ("FileName","Section","Key") This returns a string from an ini file entry

DrumMachine v1 is a beat maker prototype for designing drum patterns using real drum samples.  With it you can program beats (limited to 2 bars of 4/4 now).  It uses 16 real drum sounds to make realistic sounding patterns.  The drum patterns can be saved and loaded (it's a file named DRUMMACHINE.SAV).  This version has limited capabilities and was made to see if QB64 can handle many sounds this way, and it looks like it can.  The real drum sound samples were all found in public domain. 

The attached version is new - I fixed a problem with the one that was posted on the old forum - the mouse click no longer delays the playback, so it doesn't stutter anymore.

I'm currently working on version 2 which has more capabilities.

- Dav


  drummachine-01d-src.zip (Size: 267.12 KB / Downloads: 78)

   

TriPegs is a clone of the wooden triangle peg jumping puzzle you often see on the tables at the crackle barrel restaurants here the US.  It's a very simple puzzle to play, you just jump over the pegs, removing the peg you jump over.  The goal is to leave only one peg on the board, which gives you the genius rating.  Have fun.

- Dav


  tripegs-src.zip (Size: 146.46 KB / Downloads: 73)

   

This program generates an endless succession of artificial net attractors,
by a program of J.C.Sprott from 1989.

A description you will find in the following paper:

https://sprott.physics.wisc.edu/pubs/paper232.pdf

I made small changes to adapt it into QB64.

This is a 2D graphics library. The routines in this library are mainly (but not entirely) based on algorithms found in the book Computer Graphics (Teach Yourself) by John Landsdown (Amazingly a newer version (1997) than mine (1987) is available at Amazon UK).

There are 2 common types of graphics used with computers - tile graphics and coordinate graphics. This library deals entirely with the latter. The library is accompanied by a demo. The library consists of a BI file, a BM file and a DAT data file. The demo consists of a BAS file and it's own dedicated DAT data file.

This library uses the following conventions. The coordinate pairs are stored in a 2 dimensional array of the form CoordinateArray#(0 TO N, QX% TO QY%). CoordinateArray#(0,QX%) and CoordinateArray#(0, QY%) are used to hold the coordinates of the centre of the graphics object. The following three types are used extensively throughout this library. The type Box2D is used both for storing the coordinates of an imaginary box surrounding each graphics object and also for the storage of the coordinates for graphics windows. AView2D is used to store the device coordinates for viewports. Type Vision combines both a graphics window and a viewport as well as additional information needed for the mapping of the world coordinates (stored in the arrays) to device coordinates (so you can display them).

If the above is all Ancient Greek to you don't panic, Just compile and run the demo to get a flavour of what's here.

Before I post the library in the next post, here is the original BI file (DO NOT USE- Just read) as documentation of the public routines in the library -

Back in the day I wrote a whole trigonometry library. Looking on the wiki I see that most of what is in that library are incorporated into QB64. Most...

So what we have here are 2 constants, 3 ordinary functions and 4 conversion functions. The conversation functions deal with converting to and from another standard angle measurement type - Gradians (aka Grade). Conversions between radians and degrees are already covered in QB64. The other 3 functions just make sure that angles lie within specified bounds.

Just testing.  Nothing to see here. 

For the last month, we've been directing folks over to the old QB64 Discord channels, but here lately they've became amazingly hard to work out of.  QB64 fractured and split into half a dozen forks, and now every fork appears as if they want to argue over who's the "Official" inheritor of QB64.  It's full of drama, and emotions, and people insulting people, and as much as I hate to say it, it's just not a good place to go to actually talk about code, or the Phoenix Edition, or make suggestions or get quick feedback on a topic related to the stuff we're doing right now.

So, I've made us our own little Discord channel which is dedicated to the Phoenix Edition -- and the Phoenix Edition only -- in an attempt to put a filter between us and all the drama those other guys are generating.  All I want is a nice quiet and peaceful place where I can work and do my own stuff, and I think the vast majority of folks feel the same way, and hopefully that's what we're going to try and become at our own home on Discord.

Everyone is invited to join us there:  https://discord.gg/D2M7hepTSx

All we ask is that you stick the off-topic stuff in the dedicated off-topic channels, and leave all the fighting over which version of QB64 is going to end up being called the official version of QB64.  We're not interested in any of that drama.  All we want to do is be us, continue on as we've been continuing on, and we're more than happy to let all those other guys be those other guys.  We peacefully exist with FreeBASIC, PureBasic, and all the other BASICs out there on the whole wide web.  Why can't we peacefully tolerate the other branches of QB64, rather than fight over who gets to hold the title as being the "official" version of things.

I'll clear it up for everyone who likes to argue once and for all -- we're NOT "QB64 Official".  Never claimed to be.  We're just the Phoenix Edition, and that's what we're going to remain.  Hopefully the folks who end up visiting our private Discord will remember that.  At least, I hope they will. 

https://discord.gg/D2M7hepTSx