English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 04 January 2013, 01:15   #21
lordofchaos
TinkerTailorContentMaker

lordofchaos's Avatar
 
Join Date: Nov 2009
Location: Bedfordshire
Age: 39
Posts: 1,025
Quote:
Originally Posted by Photon View Post
If only more people would put their floppy in their A500...
The first Double Entendre I've witnessed on this board
lordofchaos is offline  
AdSense AdSense  
Old 04 January 2013, 01:16   #22
lesta_smsc
Registered User

lesta_smsc's Avatar
 
Join Date: Feb 2012
Location: United Kingdom
Posts: 1,223
I was going to suggest Chaos Engine - but there is a point where if you select the wrong numbers in one of the levels you can't complete it... might be a stupidity on my part, but I knew there was no 'fix' around this.
lesta_smsc is offline  
Old 04 January 2013, 01:33   #23
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
Quote:
Originally Posted by Mrs Beanbag View Post
If one has reserved memory using the OS functions, it is surely guaranteed the SSP won't point into it, surely? And it is possible to use interrupts in an OS-friendly way, VBL interrupts at least.
Nothing stops any stack from growing downward until it overwrites other running programs and the OS data in reserved memory. All it takes is running some fractal generator with deep settings or Quicksort a large dataset, anything that uses the stack. This is why you have the Stack command. If you don't specify a large enough stack, it will of course go down into the next lower reserved memory area.

If you start an interrupt in an OS-friendly or OS-unfriendly way, it's OK as long as you know you won't be overflowing the stack - if you allocate memory for everything in your game.

Quote:
Originally Posted by Mrs Beanbag View Post
I guess people were still programming the way they always had on the 8-bits. Up until that point home computers didn't really get upgrades
You're missing the point. Nobody can make future-compatible software, not even OS-compatible software. C= was unable to make future-compatible OS software for its own future models planned by them. Today, modern computers are still updated, and only major software packages are updated to follow suit. "Why can't I play Quake I directly from the floppies anymore? -Grmbl, shitty programmers." <- this is nonsense. And Id is actually still around!

The golden age for Amiga games was very short, only from 1985 (or realistically, 1987) to 1991 when consoles took over. It's ridiculous to expect more than 5-year support and updates from a 4-man company in Germany, France or UK for a game that cost 25 GBP.

-~-

The reason why you take over the system and use all the memory is not because you're "oldskool", but because non-trivial games require more than the ~200k left on a 512K Amiga when Workbench is loaded. If you do Workbench games, you're going to get the graphics and sound awesomeness of Sim City and Marble Madness - unless you stopped supporting the million A500s and upped the hardware requirements, leaving you 1% of the market. (Today, replace "market" with the word "audience" - although now we have more expanded machines, your hardware requirements determine your audience. AGA-060? Couple hundred can run it, if that.)

Fastmem didn't (and largely doesn't) really help games much. Here's why: You could put all the code and mapdata in it, but that would likely only use 150k for a big game. You couldn't have graphics, sounds, or misc. buffers for such in it. The point is that loading from disk was and is a replacement for loading the whole game in memory. And this is why loading from disk is an advantage to 'just write huge binary, who cares if people have memory for it'. (And yes, the reason it's trackloaded from disk and not file-loaded is that a 10yo could copy it in 5 minutes then.)

Today, the reason to make a game disk-loaded is because those who have an A500/A500+ usually don't have a harddisk interface. But the major reason is that few companies are still around that could produce a massive game that requires more than 1-2 disks of space. If the game doesn't require a harddisk to run, you shouldn't require one.

-~-

"NASA could get the HRM!". My answer to that is: well, what if you're not NASA, or not even a major developer?

If you lived outside the USA, unless you got hold of C= USA's telephone number (how?) and managed to convince them to send you the manuals you needed (how?), you were out of luck until about 1989. That's almost 4 years.

Some already established game companies were able to before that, of course, this is why you see companies like Electronic Arts and programmers who were already in the business like Archer MacLean etc. releasing software early.

But trusty documentation companies like Zybex et al had seized on the gap and published documentation for the hardware and OS, but only parts of them. Still, not even your local Amiga dealer was likely to stock books, advertising for them was scarce, the local bookstore had 20 out of 5000 books that were "computer" books, basically only word of mouth and a bunch of phone calls would make you even aware that they existed. They cost 30-40 EUR a pop, so which one?

But the main problem was that C= apparently decided you weren't supposed to code assembler for Amiga, and they made the official hardware manual correct* yet hopelessly terse and abstract. They certainly didn't write it to make you learn to program the hardware, and they taught nothing in it.

Amiga was and is a great piece of hardware and the OS impressively set the standard for how OSes work even today. C= did fail in the respect that they thought once the product was out, everything would solve itself, and so were late and lax in supporting the platform once out (and late in upgrading performance of the platform, as we know). Now, that's so bl**dy easy for someone to say 25 years later with hindsight, right?

But it's also a factual weakness, and I think some of you are taking the even more easy way out to just dismiss early Amiga coders without taking this weakness into account. I'm defending them a little.
Photon is offline  
Old 04 January 2013, 02:15   #24
Harry
HD Installer
Harry's Avatar
 
Join Date: May 2010
Location: Hamburg/Germany
Posts: 777
Quote:
Originally Posted by Photon View Post
Fastmem didn't (and largely doesn't) really help games much. Here's why: You could put all the code and mapdata in it, but that would likely only use 150k for a big game. You couldn't have graphics, sounds, or misc. buffers for such in it. The point is that loading from disk was and is a replacement for loading the whole game in memory. And this is why loading from disk is an advantage to 'just write huge binary, who cares if people have memory for it'. (And yes, the reason it's trackloaded from disk and not file-loaded is that a 10yo could copy it in 5 minutes then.)
Loading a big part of the game into memory was an advantage for those games which used in worlds (parts of) the same graphics over and over again. For this reason many track formats even had a rudimentary custom file structure on them. These parts could then be copied to expansion memory and loaded from there. I made once a version of Projectyle for me which loaded the half of the disk which contained the arenas, score boards etc. multimedia data in a 512 k expansion memory, and it showed the goal faces with 2 instead of 30 seconds delay. (A pity that the original company hadnt done this).

Otherwise, the used memory detection routines were mostly broken, until the fact that Pang detected the Amiga-XT-Brigdeboard-Card-State-Transfer area as ram, crashing the Game, because the XT-Side modified the data. The ONLY correct way to detect a ram area is to allocate it with the OS, eg allocate from $80000-$d0000 in chipmem with AllocAbs and later assume that that are 512 k. Same for Non-Chip-Ram: Allocate the largest free "Fastram" block, make sure it is larger than 256 k (to exclude these small expansions), and clip its boundary to a 512 k border; in the case of old customized handmade hd installs you may also leave the odd start if the game runs with it and it is large enough.
Harry is offline  
Old 04 January 2013, 03:24   #25
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
Quote:
Originally Posted by Harry View Post
[re:Rock'n'Roll original]
I have played it a lot, and hung it a lot until I learned not to try to roll out of an abyss, but use the parachute instead.
Do we mean the same thing? Just tried my original now, just a couple levels, and it just gives me the option to continue or restart level when I fall into an abyss, just like the cracked version I played back in the day. The disk says 'SLB65', if that's some sort of version code.

I believe you of course, and there's no question that 'hangs if you do this and then that and then crouch for too long if you qualify for a bonus level on level 21' (my poor attempt at describing hard-to-playtest bugs) or the Atomix example (which is hopefully not as intended, like cracker hiscore hogging ) is annoying as hell, but the thread is about clean code. A game can be very well-written and depending on the game's complexity the coder could have not been able to test every combination. He could even have made simple mistakes like the Atomix example, and the code would still be well-written, if you know what I mean. (Note however that I couldn't say the game code in Atomix wasn't utter shit or the ultimate perfection, see below for why.)

As opposed to the likes of misc. early arcade conversions like Soldier Of Light, 2.5D driving games that are not Vroom or Lotus, various horrible beat'em-ups and other tripe made in a couple months to cash in on some license.


Regarding bugs, I just don't think I could have been so lucky as to have virtually no problems playing mostly cracks from 1987-1990 and mostly originals from 1991-now on my A500 and never had any real trouble. A few games crashed of course, but it was always fixed with a proper crack or an error-free copy.

Most of the games passing by on my A500 were made before 1992, though. I can't say anything about AGA games, for example, since I've not really played them a lot.



I think there's been enough talk about bugs though. If I were to give a go at recommending clean game code for coders to look at, I'm afraid it would just be another list of famous names; Braben, Crammond, MacLean, Braybrook, et al. Not Minter though. (So spank meh, I'm pretty sure it's the truth )

I think it's more interesting to look at what games did something new. Here, some interesting things pop up. Lemmings (Dave Jones), Worms, Silk Worm, Maggots, Lentils (just kidding), Nebulus (Phillips), Eliminator (Weber), Exile (Irvin/Reeve), Another World (one-man game creator hero Eric Chahi!) and so on.

Some games did something new by nearing performance limits: Turrican II, X-Out, Mega Typhoon, Unreal. It's very likely that instead of clean, neatly ordered code you will see code that sells its own mother to gain 4 cycles (ahem, so to speak).

-~-

So, do you want to see *great* code or clean code? Or do you want a flawless game, however trivial or boring, as long as you can complete the dorky game without seeing a single flaw?

A bit exaggerated, but I think it's a good viewpoint. You take the bad with the good, if it's crap you don't play it and if it's good but crashy/unplayable you ask the WHDLoad heros to please fix it for free for you
Photon is offline  
Old 04 January 2013, 03:42   #26
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
Quote:
Originally Posted by Mrs Beanbag View Post
The other thing that can screw things up is writing wherever you want in memory instead of using the OS functions to reserve memory, that's just plain lazy as far as I'm concerned, there's no excuse and you're just making trouble for yourself.
Remembering the early days of A500s with only 512k, you can either use the O/S to cleanly allocate memory and lose 64k (or more?), or throw the lot out and do it yourself with the full 512k. I'm glad the coders back then just hit the hardware, a lot of games used the full 512k and could not do that otherwise!
Codetapper is offline  
Old 04 January 2013, 04:13   #27
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
Quote:
Originally Posted by Harry View Post
Loading a big part of the game into memory was an advantage for those games which used in worlds (parts of) the same graphics over and over again. For this reason many track formats even had a rudimentary custom file structure on them. These parts could then be copied to expansion memory and loaded from there. I made once a version of Projectyle for me which loaded the half of the disk which contained the arenas, score boards etc. multimedia data in a 512 k expansion memory, and it showed the goal faces with 2 instead of 30 seconds delay. (A pity that the original company hadnt done this).

Otherwise, the used memory detection routines were mostly broken, until the fact that Pang detected the Amiga-XT-Brigdeboard-Card-State-Transfer area as ram, crashing the Game, because the XT-Side modified the data. The ONLY correct way to detect a ram area is to allocate it with the OS, eg allocate from $80000-$d0000 in chipmem with AllocAbs and later assume that that are 512 k. Same for Non-Chip-Ram: Allocate the largest free "Fastram" block, make sure it is larger than 256 k (to exclude these small expansions), and clip its boundary to a 512 k border; in the case of old customized handmade hd installs you may also leave the odd start if the game runs with it and it is large enough.
Yup. Of course you can buffer disk tracks (or files) in any type of memory. The thing is, that is optional - i.e. doesn't up the hardware requirements - in other words a great option Using fastmem for real-time buffering (which is obviously what I meant above) is very limited - mostly you can only use it to save loading (And this is also how it has been used since slowmem expansions became commonplace. Before that, assuming 'everyone' had it limited sales.)

Loading on any computer has throughout time been used as just a way of extending RAM to a slower memory. That's how it was used to make more impressive games than just 512K allowed, and that's how modern games fit GB of textures on a 512MB graphics card today.

(You know all this of course, but if everyone on the forum spoke to experts only it would be a forum that excluded people.)


What I think is important isn't whether some old game crashes on some Amiga hardware combo today, but whether there will ever be a substantial amount of excellent and absorbing new Amiga games in the future.

I've had my company since forever and many times I've planned to give it a try, only to go "oh, who are kidding, who's going to care." I registered amigafuture.com at one point to set up a kickstarter.com-like community where anyone could post a project plan (or at the very least a luxurious showcase of projects for people to gather round), but again the doubt. (And the life(tm) and time and new interests factors.) I'd leave my job and work full-time as Amiga game coder for my company in an instant. I have a simple almost-finished game and an Exile/Gravity-Force game that is playable but only one level on my harddisk, but how do I make a living? It's hopeless. I'm sure I'm not alone in this feeling.

Elite: Dangerous got funding on kickstarter.com on the second try just now, and that's good. (And the money is insane!) But it's not an Amiga game. Who cares.

Well, I do. And others do. But more people caring with their time and money, that's a challenge. It's obviously not impossible, just - a - bit - hard.

OK, I better stop 'opening up' now. Before I give you all chronic depression. Haha, good night
Photon is offline  
Old 04 January 2013, 13:27   #28
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Photon View Post
If you start an interrupt in an OS-friendly or OS-unfriendly way, it's OK as long as you know you won't be overflowing the stack - if you allocate memory for everything in your game.
This is always a potential pitfall no matter how you code it. Not sure why anyone would generate a fractal from an interrupt, but never mind.

Quote:
You're missing the point. Nobody can make future-compatible software, not even OS-compatible software. ...
The golden age for Amiga games was very short, only from 1985 (or realistically, 1987) to 1991 when consoles took over. It's ridiculous to expect more than 5-year support and updates from a 4-man company in Germany, France or UK for a game that cost 25 GBP.
True up to a point, but if a game crashes with addition of fast ram, or from kickstart going from 1.2 to 1.3, or 2.0, surely that's just not even trying. Some things perhaps you can't be expected to predict. I don't think we could blame a coder in 1985 for not foreseeing the 68020's instruction cache for instance (which is not even Commodore's responsibility anyway), then again is self-modifying code ever really necessary or is it just showing off/hacky coding style?

Quote:
The reason why you take over the system and use all the memory is not because you're "oldskool", but because non-trivial games require more than the ~200k left on a 512K Amiga when Workbench is loaded.
You can boot from floppy and still use exec/dos library calls. But I guess there is still some overhead. I remember there was an Add21k command that disabled external disk drives or something.

Quote:
Fastmem didn't (and largely doesn't) really help games much. Here's why: You could put all the code and mapdata in it, but that would likely only use 150k for a big game. You couldn't have graphics, sounds, or misc. buffers for such in it. The point is that loading from disk was and is a replacement for loading the whole game in memory. And this is why loading from disk is an advantage to 'just write huge binary, who cares if people have memory for it'. (And yes, the reason it's trackloaded from disk and not file-loaded is that a 10yo could copy it in 5 minutes then.)
You can store music pattern data in Fastmem also... Insider information: Mr Beanbag stores all its game data in one big (>600k) datafile but it only opens this file and doesn't read it all into memory, rather, it loads it piecewise as required, like a sort of trackloader-in-a-file.

Quote:
If the game doesn't require a harddisk to run, you shouldn't require one.
I agree entirely.
Mrs Beanbag is offline  
Old 04 January 2013, 13:41   #29
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by pmc View Post
Also @Mrs Beanbag - I think views on how to use the hardware and its resources very much depend on your perspective. I tend to share the same perspective as Photon in that my personal preference is to take over the hardware and do whatever I like but the ultra clean approach you advocate is, in my view, equally valid depending on the circumstances.
There was a time in the past when I would have advocated the direct approach. Since then I think programming professionally in C++ has given me good habits, but Commodore didn't even want people touching the hardware registers directly, in vain have I tried to explain to my dad that writing anything impressive practically requires that you do this.

Nevertheless in future I intend to go so far as to attempt to get things to run in an Intuition screen. I perfectly understand game coders NOT doing this even to this day. Perhaps it's the opposite sort of showing off...
Mrs Beanbag is offline  
Old 04 January 2013, 15:59   #30
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
Quote:
Originally Posted by Mrs Beanbag
Nevertheless in future I intend to go so far as to attempt to get things to run in an Intuition screen.
You can certainly still get lots done that way. Even some commercial games did things in a system friendly way. I think I'm right in saying (someone here will *definitely* correct me if I'm wrong ) that Rocket Ranger, for example, had animated graphics and sound etc. but all done in a system friendly way.
pmc is offline  
Old 13 January 2013, 00:49   #31
breech
Asking stupid questions
breech's Avatar
 
Join Date: Sep 2009
Location: Syd.Oz
Posts: 123
I'm not an expert on coding or compression but going by filesizes, content, quality and conversions, Geoff Crammond's Stunt car racer has always impressed me.
breech is offline  
Old 13 January 2013, 20:40   #32
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,604
Quote:
Originally Posted by pmc View Post
You can certainly still get lots done that way. Even some commercial games did things in a system friendly way. I think I'm right in saying (someone here will *definitely* correct me if I'm wrong ) that Rocket Ranger, for example, had animated graphics and sound etc. but all done in a system friendly way.
System friendly as in using the system to display graphics and the like, but not using an intuition screen.

Frankly, using intuition is fine if you want to mode promote and use graphics cards and all that kind of fun stuff, but, you'd best make sure that your game is good enough to warrant needing those kind of resources, and be prepared for hardly any real Amiga owners to ever get to play it.
Galahad/FLT is offline  
Old 13 January 2013, 21:21   #33
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Might just do the title screen that way. But it would be cute to be able to click it to the back and go back to your workbench.
Mrs Beanbag is offline  
Old 13 January 2013, 23:54   #34
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
What Galahad said, plus I'd say even without enhancing the graphics, 100% of the system-friendly games would crash badly if just promoted to some Truecolor mode

It's much more important to make an enjoyable game than to make it either OS-friendly OR hardcore superfast optimal hardware code. The former can be a selling point in a puzzle game ('for a quick romp', like Tetris) and the latter can be a selling point in a normal arcade action game, but that first point is always the hard one, and it's basically the same for all platforms.

breech: well, it doesn't have much graphics at all, barely any sound/music, and very simple levels. There isn't much there to take up any space, basically
Photon is offline  
Old 14 January 2013, 09:44   #35
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,591
Quote:
Originally Posted by Mrs Beanbag View Post
then again is self-modifying code ever really necessary or is it just showing off/hacky coding style?
If you want the fastest possible code on 68000 there sometimes is no way around SMC! Often SMC is just used because of laziness of the coder though.


Quote:
Originally Posted by Mrs Beanbag View Post
Mr Beanbag stores all its game data in one big (>600k) datafile but it only opens this file and doesn't read it all into memory, rather, it loads it piecewise as required, like a sort of trackloader-in-a-file.
You make it sound like this is something special but this has been done since the beginning of the Amiga already. Also, while it works fine of course, you'll run into quite a bit of trouble if you want to do the same with a completely dead OS. In that case a trackloader is still the better choice.
StingRay is offline  
Old 14 January 2013, 15:03   #36
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by StingRay View Post
If you want the fastest possible code on 68000 there sometimes is no way around SMC!
Can you think of an example?

Quote:
You make it sound like this is something special but this has been done since the beginning of the Amiga already. Also, while it works fine of course, you'll run into quite a bit of trouble if you want to do the same with a completely dead OS. In that case a trackloader is still the better choice.
This does not surprise me, it seemed like an obvious thing to do. Of course one of my design goals was to make it easy to run from hard disk, which I don't imagine early games programmers were really concerned about. Of course you need to be OS friendly in order to do this.
Mrs Beanbag is offline  
Old 14 January 2013, 19:43   #37
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,591
Quote:
Originally Posted by Mrs Beanbag View Post
Can you think of an example?
Of course. Take a simple matrix rotation for example. Instead of storing the calculated matrix values in a buffer and then reading back these values in the rotation routine you use SMC, i.e. change the instructions which use the matrix values. Saves you one memory read -> faster code. There are other examples too, think dot effects or 1 instruction/pixel texture mappers etc. Another classic example for SMC are 50 FPS rotation zoomers.

Quote:
Originally Posted by Mrs Beanbag View Post
Of course you need to be OS friendly in order to do this.
It's possible when the OS has been disabled too but you need some "trickery". Used it in some of my demos (Worldcharts 15/Scoopex, Tribute/Scarab and others). It does work best when the OS is completely alive though.

Last edited by StingRay; 14 January 2013 at 19:52. Reason: added rotation zoomer example
StingRay is offline  
Old 16 January 2013, 17:03   #38
lordofchaos
TinkerTailorContentMaker

lordofchaos's Avatar
 
Join Date: Nov 2009
Location: Bedfordshire
Age: 39
Posts: 1,025
As this thread has attracted lots of you coder types I was wondering if you could explain something for me (in laymens terms if possible)

I was playing Uridium 2 on the A500 recently and I noticed during the title/credit sequence slowdown was occurring (the text display routine), however the star field scroller in the background remained constant with no slow down. I have noticed this before with other games on the Amiga but not on other machines. Is this unique to the Amiga architecture or is it coder specific?
lordofchaos is offline  
Old 16 January 2013, 18:46   #39
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 710
that is definitely "coder specific" as you call it.. The stars are probably rendered directly in the vertical blank interrupt, while the text rendering runs outside this interrupt and gets whatever leftover processor time is available...
hooverphonique is offline  
Old 16 January 2013, 20:30   #40
demolition
Unregistered User
demolition's Avatar
 
Join Date: Sep 2012
Location: Copenhagen / DK
Age: 37
Posts: 3,384
If it stays choppy even when running on a faster Amiga, it's maybe clocked to an interrupt every 2nd frame (because they couldn't make it finish in one frame on the model it was designed for).
demolition is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Most memory efficient way to run WHDLoad on a 2MB A600? e5frog project.WHDLoad 2 25 July 2010 20:41
remakes on amiga ??? coders wanted turrican3 Retrogaming General Discussion 24 03 October 2007 19:33
Amiga Coders Club (ACC) Daillew request.Other 5 24 July 2007 10:22
A huge challenge to all the Amiga coders/hackers out there! JohnnyWalker project.CARE 6 14 June 2005 23:04
Calling all amiga coders/gfxrs/etc... [crazy :P] Amiga Game Project! Akira Amiga scene 81 29 June 2004 05:10

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 20:50.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.38458 seconds with 11 queries